"Unit test" is a misnoner :(
When people think of unit testing, they think it tests the "smallest" unit of your program -- whatever they mean by that.
Truth is that you can test anything in a "Unit" test - you can test the biggest, highest level method on your program. You can test module integration, database transactions, input parsers, loggers, etc.
"Unit" means that you are testing ONE thing - whatever that one thing might be. Secondly, a Unit test must be INDEPENDENT of other Unit tests. If there are two unit tests A & B, neither of them should have any effect on the other. Whether I run B after A, or A after B, whether one fails or succeeds -- nothing will affect the results of the other.
For this, each unit test should create its own Initial state so that it becomes isolated from the unit tests before it.
This is what ensures that when you have 1000s of unit tests, if unit test# 537 fails, you know immediately what in your program has a problem. Because test # 537 is testing something very specific, and it is not dependent on the results of the other 536 tests that ran before it.
(Ideally, it should clean up its state when it ends so that it does not affect the tests after it - but strictly, this is not necessary because the next test is responsible for its own state initialization.)
The more the unit tests, the better the program gets tested. Even more importantly, you can refactor your code with confidence. Leave it to the unit tests to ensure code integrity.
No comments:
Post a Comment