Test Responsabilities
time to read 2 min | 224 words

Jermey Millier talks about lines of codes in tests vs. productions, and he raises an important issue with regard to the tests:

I say that mainly because unit test code is composed almost entirely of stand alone methods.  They don't interrelate or interract with each other.  The responsibility of a unit test is almost always the same:  setup data, do something, check the results.  The hardest thing about coding is deciding what to code, not the mechanical act of typing. 

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.

0 comments
Tags:

Related posts that you may find interesting:

31 Mar 2006 Rocky Lhotka on TDD, Take #2
Programming Test Driven Development XP
30 Aug 2006 Clarifying interaction based testing
Design Rhino Mocks
02 Jan 2012 Structuring your Unit Tests, why?
Test Driven Development