The Three Laws of TDD
First Law : you may not write production code until you have written a failing unit test.
Second Law : you may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law : you may not write more production code than is sufficient to pass the currently failing test.
These three laws lock you into a cycle that is perhaps thirty seconds long.The tests and the production code are written together,with the tests just a few seconds ahead of the production code.
Keeping Tests Clean
Dirty tests is equivalent to, if not worse than, having no tests.The problem is that tests must change as the production code evolves.The dirtier the tests, the harder they are to change.The more tangled the test code, the more likely it is that you will spend more time cramming new tests into the suite than it takes to write the new production code.As you modify the production code, old tests start to fail, and the mess in the test code makes it hard to get those tests to pass again.So the tests become viewed as an ever-increasing liability.
Test code is just as important as production code.Its is not a second-class citizen.It requires thought, design and care.It must be kept as clean as production code.
Tests Enable the -ilities
Unit tests keep our code flexible, maintainable and reusable.Having an automated suite of unit tests that cover the production code is the key to keeping your design and architecture as clean as possible.Test enable all the -ilities, because tests enable change.
Clean Tests
Readability is perhaps even more important in unit tests than it is in production code.What makes tests readable?The same thing that makes all code readable: clarity, simplicity and density of expression.In a test you want to say a lot with as few expressions as possible.
The tests get right to the point and use only the data types and functions that they truly need. Anyone who reads these tests should be able to work out what they do very quickly, without being misled or overwhelmed by details.
Domain-Specific Testing Language
Rather than using the APIs that programmers use to manipulate the system, we build up a set of functions and utilities that make use of those AOIs and that make the tests more convenient to write and easier to read.These functions and utilities become a specialized API used by the tests.They are a testing language that programmers use to help themselves to write their tests and to help those who must read those tests later on.
A Dual Standard
The code within the testing API does have a different set of engineering standards than production code.It must still be simple, succinct and expressive,but it need not be as efficient as production code.
There are things that you might never do in a production environment that are perfectly fine in a test environment.Ususally they involve issues of memory or CPU efficiency.But they never involve issues of cleanliness.
One Assert per Test
There is a school of thought that says that every test function in a Junit test should have one and only one assert statement.This rule may seem draconian, but the advantage can be seen that those tests come to a single conclusion that is quick and easy to understand.
Notice that I have changed the names of the functions to use the common given-when-then convention.This makes the tests even easier to read.Unfortunately, splitting the tests as shown results in a lot of duplicate code.
We can eliminate the duplication by using the TEMPLATE METHOD pattern and putting the given/when parts in the base class, and then parts in different derivatives.Or we could create a completely separate test class and put the given and wehn parts in the @Before functions, and the when parts in each @Test function.But this seems like too much mechanism for such a minor issue.
Single assert rule is a good guideline.I usually try to create a domain-specific testing language that supports it.But I am not afraid to put more than one assert in a test.I think the best thing we can say is that the number of asserts in a test ought to be minimized.
Single Concept per Test
Perhaps a better rule is that we want to test a single concept in each test function.We don't want long test functions that go testing one miscellaneous.
F.I.R.S.T
Clean tests follow five other rules that form the above acronym:
Fast -- Tests should be fase.They should run quickly.
Independent -- Tests should not depend on each other.One test should not set up the conditions for the next test.You should be able to run each test independently and run the tests in any order you like.When test depend on each other, then the first one to fail causes a cascade of downstream failures, making diagnosis difficult and hiding downstream defects.
Repeatable -- Tests should be repeatable in any environment.You should be able to run the tests in the production environment, in the QA environment, and on your laptop while riding home on the train without a network.
Self-Validating -- The tests should have a boolean output.Either they pass or fail.You should not have to read through a log file to tell whether the tests pass.You should not have to manually compare two different text files to see whether the tests pass.If the tests aren't self-validating, then failure can become subjective and running the tests can require a long manual evaluation.
Timely -- The tests need to be written in a timely fashion.Unit tests should be written just before the production code that makes them pass.If you write test after the producion code,then you may find the production code to be hard to test.You may decide that some production code is too hard to test.You may not design the production code to be testable.
Conclusion
We have barely scratched the surface of this topic.Indeed, I think an entire book could be written abut clean tests.Tests are as important to the health of a project as the production code is.Perhaps they are even more important,because tests preserve and enchance the flexibility, maintainability, and reusability of the production code.