Ideally unit tests should written as a part of a test driven design (TDD), in this case they check for code's correctness. However, sometimes the unit tests don't get done
instead the code is made bug-free by testing it by hand. In this case it is still of value to write unit tests, however the focus changes: The unit tests should guard the code against external changes that affect it, i.e. ensuring its pre-conditions. These unit tests test things such as:- DB schema changes: E.g. the code should still be able to load its configuration from the database.
- Interfaces to external code: Just the simplest run through the code where all external interfaces are called should trigger test failure. This is not such an issue for strongly types languages, except where reflection is used.
1 comment:
I agree with your point. TDD is the holy grail of software development and should be considered best practice. In the real-world environment it is 'not always' (maybe not at all in the majority of cases) realised. TAD (Test After Development :) is on the other hand very important since it guards your code (design) against regression bugs and errors. That is when some other seemingly uncorrelated change in other code causes your code to fail.
Or as Robert C. Martin (Uncle Bob) puts it: "If you don't have (automated) tests of your code you have no way of knowing that code working today will work tomorrow"
Post a Comment