Related Work


Fowler presents a large set of bad smells and the refactorings that can be used to remove them [Fowler1999]. The difference between his work and ours is that we focus on smells and refactorings that are typical for test code, whereas his book focuses more on production code. The role of unit tests in [Fowler1999] is also geared more toward proving that a refactoring didn't break anything than to being used as documentation of the production code.

Instead of focusing on cleaning test code that already has bad smells, Schneider describes how to prevent these smells right from the start by discussing a number of best practices for writing tests with JUnit [Schneider2000].

The introduction of Mock Objects [Mackinnon+2001] is another possibility for refactoring more complex tests. With this technique, one replaces parts of the production code with dummy implementations that both emulate real functionality and enforce assertions about the behavior of the code. This enables the tester to focus on the concrete code that has to be tested without having to deal with all surrounding code and the side effects that it may cause.

The C2 Wiki contains some discussion on the decay of unit test quality and practice as time proceeds and on the maintenance of broken unit tests.[2] Opinions vary between repairing broken unit tests, deleting them completely, and moving them to another class to make them less exposed to changes (which may lead to our Indirect Testing (8) smell).

[2] See http://c2.com/cgi/wiki?TwoYearItch and http://c2.com/cgi/wiki?RefactorBrokenUnitTests.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net