Issues with testability boil down to our inability to write tests or the excess trouble we have to go through to get it done. The article “Guidelines for Java Testable Design” is excerpted from the Unit Testing in Java book by Lasse Koskela. In this extract shares a set of dos and don’ts for testable design and recommends to avoid complex private methods, static methods, logic in constructors and to favor composition over inheritance. He also suggests to treat the new keyword with care because it essentially hardcodes an implementation we cannot substitute.
Dependencies management is a difficult part of test-driven development (TDD). Mocks and stubs are created to isolate the behavior we would like to test. The article “The Art of Mocking” is a good introduction on this topic. Creating all these testing classes by hand can lead to troubles, but several open source tools to apply mocking principles in .NET. Tools like Rhino Mocks and Moq allow us to create mocks and stubs within our test method. The Mocking Frameworks in .NET video presents techniques that can automate your unit testing process.
This article covers the subject of software testing mocks (also known as test doubles, stubs and fakes, amongst other names). It compares also the creation manual mocks with the usage of a full-fledged mocking framework with examples in .NET.
A recent Methods & Tools poll examined how organizations perform unit testing. Is it an informal activity that is done before integration if there is some time left after programming or is it the key element of the development effort? The question was: How is unit testing performed at your location?
|Unit testing is not performed||17%||13%|
|Unit testing is informal||40%||46%|
|Unit tests cases are documented||9%||11%|
|Unit tests cases and their executions are documented||14%||16%|
|We use a Test Driven Development approach||20%||14%|
Participants: 384 (2006:460)
Ending date: October 2008 (February 2006)
Despite the fact that the number of TDD adopters has grown nicely since the previous survey, you can notice that unit testing is still widely conducted in a informal manner, when it is not simply ignored by developers. This could sound weird when many people announced a general adoption of the agile approaches, but the results of our survey are similar to many other polls on the same topic.
Comparing the two surveys, it seems that people that were already doing unit testing formally have switched towards a TDD approach. People that don’t do unit testing have different reasons. Some will consider simply that they don’t add value to their development process, which is sometimes difficult to believe. For others, it is the lack of time, a reason more easier to understand ;o) Many complains that unit test are hard to write, but creating a good unit test is a proof that you understand what your code should do. I agree however, that it could be difficult to maintain large libraries of unit testing scripts if requirements are changing constantly. In the “good” reasons not to perform unit testing, some thinks for instance that the client side of Web application is not suited for this kind of tests. There are also some organizations that have separate testing teams. Their developers will rely entirely on the QA guys to test their application. You can also consider that when the software has a very limited life expectancy, it is not worth making unit tests.