Unit Tests make good Units?
August 22nd, 2003 by Hen[In reply to Mark Mascolino’s comment]
Yep. Many of the changes that switching to a testable Unit forces you to make are good long term decision ideas.
The problem is that it’s hypocritical. If we take extreme programming for example, it tells us to not overdesign and just to code what we need now, and yet we have to design more than we need just to make the unit tests work.
I end up making many of the design decisions I would have made in a ‘guess the future’ situation, to satisfy the unit tests. The only way to solve this is to say that Unit Tests create Units which are implicitly good, and yet I think this is a very bad assumption to just accept. How do I prove that the changes a Unit Test enforces on a Unit are good for the Unit?
A Unit Test should be a Watcher on a Unit, and not affect it in any way. Maybe there is an Uncertainty Principle for Unit Tests, it is impossible to test a prepubescent Unit without affecting the design of a Unit.
This leads to the fact that Test Driven Development affects the design of an application. While it might be easier to code TDD, and safer to code TDD, is it necessarily better? Or more efficient?
[Also, I wonder how much of this is just JUnit’s implementation].
August 24th, 2003 at 1:50 am
Great insight! I think you came upon something interesting when you speculated that a lot of this has to do with JUnit’s implementation. I would go a step further and say that the design of Java also has something to do with it. I think things would be a lot different if say Smalltalk was used. Also, extending this to the inclusion of Mock Objects in your unit tests, how much easier or different would things be if certain parts of the JDK were more easily mocked (i.e. more Interfaces w/ replacable implementations rather than final naked concrete classes).
I haven’t looked at any of the other unit testing tools for Java so I couldn’t say if they are any different than what we have with JUnit.