I like to keep my unit tests pretty simple and easy to follow. I often hardcode the expected results of a test in order to avoid repeating the code that I am testing. In addition, I often use data-driven tests. For example, if I am testing the format that a date/time is presented as, I will sometimes hard-code the expected string, ie. "1/1/2000" or "1:00 PM". However, since date and time formats are culture-specific and our app is localizable, the actual output COULD vary. However, my team is based in the U.S. and so this is usually not a problem. Our continuous integration and build servers run with U.S. culture info as well.
There is a team member who has complained because he has changed the date format on his dev machine to manually test other date formats, and so many tests fail for him. Should I be using the current culture information when testing outputs in unit tests, or is this hard-coding acceptable?
UPDATE: I ended up setting a specific locale for certain tests.
Developers are often tempted to copy the seemingly simple parts of code from their SUT into their unit tests. As Winston points out, those can still have tricky bugs hidden in them. "Hard-coding" the expected result helps to avoid situations where your test code is incorrect for the same reason that your original code is incorrect.
But if a change in requirements forces you to track down hard-coded strings embedded inside dozens of test methods, that can be annoying. Having all the hard-coded values in one place, outside of your testing logic, gives you the best of both worlds.
- The answer is NO since, in general, you should never make assumption about the code which you are testing. If this is not done properly, over time bugs become immune to some unit testing.
- The answer is NO since, in general, you should never make assumption about the code which you are testing. If this is not done properly, over time bugs become immune to some unit testing. 2. Hardcoding should you hard code? Again the answer is No. because like any software - the hard coding of he information becomes difficult when things evolve.
Unit tests should be 100% repeatable, regardless of the environment in which they run. The only reason for a unit test to start failing is because the code changed and broke the test.
So yes, you need to take steps to ensure that your tests continue to pass regardless of external factors.
It is, of course, okay to hard-code the result, but you'll need to provide a test-double for the locale information to ensure that the unit test is isolated from the environment.
You could even add a new unit test with a test-double emulating the other developer's locale settings.
Your unit tests should run and pass on any machine.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With