DoingUnitTesting

MockObject's can help you isolate a unit to be tested, but it is acceptable to use other objects during a test so long as you already have tests for those other objects.

One of the most often heard objections to unit tests is that it will take too long and my code is just too complex to be tested that way. This never turns out to be true. Any part of your program that goes into production is going to undergo change. That means you will need to test it numerous times during its life. If you do not write automated unit tests you will be testing it by hand. So clearly, the harder something is to test the more time you will ultimately save by making those tests unit tests that can be run by pressing a button.

Here's a question on TestingAbstractClasses

A discussion on MockObjectsAndDemeter.

I reckon unit testing is about gathering evidence to help you make the decision to release or not to release. The amount of evidence you need is determined by your belief in how bad the consequences of the code not working will be and how likely you believe errors are likely to be. Thus you test getters and setters on control system code (consequences of failure are severe) and if no-one is going to use your code you don't test anything :). I think an important part of the process is adjusting your beliefs about where bugs will be based on experience with similar code. By the way I think AcceptanceTests play the same role from the perspective of the customer.

I think this misses an important point of unit testing within XP - you should write the tests *first*. It is about design as much as about testing. In XP you should:

• write a unit test
• write just enough code to make the test pass
• Repeat until there is nothing left to write tests for
• refactor