Today I learned a frustrating yet great lesson about Unit testing. I was working on a problem that did something relatively simple. Took in a time duration and then from that produced an array of dictionaries. Relatively simple right? Obviously all information that was needed came straight from hard coding and the only thing that was variable was the time duration which was handed in as a String in milleseconds. Simple right? Well this is where I went wrong.
My assumption was that we were dealing with milleseconds being passed in and that ended up not being the case. Instead we were taking in a time format of hh:mm:ss so that was definetly my bad. Now getting to the unit testing I went ahead and wrote unit tests for it and they were fine, covered all edge cases etc. The problem was that since I was using Unit tests I had put myself into my own world where I thought the duration handed in was milleseconds. After finally writing all of my code and “verifying” it through unit tests I went ahead and submitted my pull request. Of course it was found (thankfully) that I had messed up.
After this I realized that when using Unit tests they should attempt to reflect the real world as much as possible. What I mean by that is, in this case I had just simply put in a random duration thinking its ok, time is a universal measure. I just missed that it is not universally communicated in the same protocol. So when going to put in values into a unit test they really should reflect everything that is expected in production. What I mean by “Don’t krutch on it” is don’t rely on your unit test that you wrote to be able to verify your code. Run it through qa or production type data , NOT ON that data, just use data that resembles it. Just like writing code, a unit test can also be flawed.
Needless to say I was extremely frustrated with myself. So with that I took away these two things.
Anyways I hope this helps you the next time that you are writing your tests. Thanks for reading.