+972 52-548-6969
Test Responsabilities
Jermey Millier talks about lines of codes in tests vs. productions, and he raises an important issue with regard to the tests:
This worth repeating. The tests are not a good place to show off how smart you can be with regard to design patterns and triple indirect factories. About the only refactoring that I would do in the tests (aside from rename method) is to refactor the creation of the test data, even then, the names are something like: CreateCustomer_WithTwoOrders_ButWithNoCredit(), I am asserting on the data from this method, so it has better be clear, and easy to find.
A good test, assuming that I understand the technology that is tested, and the testing/mocking framework, so reveal its intent, preferably via its name, but from the code as well.
Comments
Indeed. Unit tests should be simple and straightforward wherever possible.
The goal of a good unit test framework should be to isolate non-essential testing concerns (such as specifying mock object behavior) so that the bulk force of the testing effort can be brought to bear on the essential problem: specifying the expected outcome.
To that end, test patterns, factories, constraints, indirection, and other techniques should largely be applied with the objective of clarifying the expression of the test specification, of validating the intent of the test itself, or of facilitating diagnostic efforts to identify the cause or extent of a failure. Thus can the provision of advanced features such as DSLs, models, declarative markup, and rich reporting be justified.
Comment preview