> Unit test thus get written for part that we absolutely want to be maximum certain of that it works correctly.
I hear this kind of rhetoric a lot, but rarely do I hear of code that doesn't need to work correctly.
I hear this kind of rhetoric a lot, but rarely do I hear of code that doesn't need to work correctly.
The difference is having code for which having some bugs is acceptable, vs having code for which bugs are not acceptable.
There is definitely code for which having some bugs is acceptable: think about some small feature that the user can totally do without. I had to do one recently, and bugs were acceptable, as long as it was shipped in time, and working for the client specific devices. That code shipped with no automated test (testing is done manually), and a few known bugs not worth solving. On the other hand, anything that touch core features must be tested.
An issue with that is bus factor when it needs to be changed in the future. What if the original dev isn't around any more?
Also, the code has been reviewed and is documented.
Bus factor really isn't a problem in the instance I was talking about. In fact, the original dev won't be around in a few months, and that's fine. The rest of the team will be able to modify the code.
A graphical error that prevents users from being able to use the application at all can be basically the same as server downtime in terms of impact to the end user.
On the other hand if the code responsible for the styling of some menu is not working correct, the functionality may still work, and once we discover the bug we can simply fix it.
> rarely do I hear of code that doesn't need to work correctly.
So there are different grades. That's why I used the word maximum. The cost for these unit test should pay bank, even during the dev't phase, IHMO. There are often areas in a large code base for which this hold true, and often they can be identified as such beforehand; then writing these tests should be a priority.