D.R.Y. and D.A.M.P. are acronyms that are used in the context of designing unit test suites. In contrast to the terms dry and damp they are not mutually exclusive though. Let me explain.
F.I.R.S.T. let us look at the characteristics of a well written unit test
A unit test should be
- Fast | execute in milliseconds
- Independent | we should not spend any time spinning up databases or loading dependencies
- Repeatable | they should be able to run N times and produce the same result N times
- Self-Validating | expanding on the two previous points, the test has everything it needs to work out if it has passed or not – no external system should determine if the test has passed or not
- Timely | both as in timely written and available when required (covering a large amount* of the custom code in the system)
*Yes – I know – people say you should cover all your code, but let’s be realistic
To achieve the qualities outlined above, we can use the two acronyms D.R.Y. and D.A.M.P. to remind ourselves of some good design principles for unit tests.
- Do NOT
It makes sense to write unit test code in as few lines as possible, as code is always a liability. (be it in the testing assembly or the main product)
As with normal software development – from a commercial perspective – if we can write less code to achieve the same goal, we make a larger profit and deliver value quicker.
Another thing to mention here is that we can use test frameworks to help us achieve this goal. We can – for example – work with test fixtures to reduce code duplication.
Yes, I agree, this does not roll of the tongue quite as easily as D.R.Y.
The point here is that no code is any good if we need a couple of pages of documentation to be able to read it.
With tests, this is even more important. We need to make sure it is obvious what is being tested and what the result of the test is.
Often we might need to compromise on D.R.Y. a little bit for the sake of readability.
In the long run this is not a contradiction of D.R.Y. though, as we would only have to spend time later refactoring and documenting the unreadable code we wrote in the spirit of D.R.Y. while ignoring D.A.M.P.
To achieve maximum “dampness” 😉 you can explore mocking interfaces, align your test names to BDD specs, and work with different design patterns to reuse and abstract test code to make it more readable.