TechEd Barcelona – Day 3 – The Future of Unit testing

Written by Yves

November 13, 2008

<Disclaimer>This is personal notes of what I retained during the session. This can be incomplete, partially right or wrong. It is just  part of the notes I took and what retained my attention. Nothing prevents the user to get more information on their favorite web site.</Disclaimer>


Roy Osherove is also one of my favorite speaker….and, once again, while waiting for the start of his presentation, he plays guitar (Nirvana, for example), which is a good for a wake up session 🙂
He starts by establishing the current unit testing market. One of his conclusion is that even NUnit has the biggest market share, there are better frameworks out there, such as Selenium, Watir, Watin, Pex and others. The problem is not the frameworks, but how to simulate or fake external systems (mock), or how to do thread testing. For example, Chess, which will be release with Visual Studio 2010, will allow to do thread testing (race condition, deadlock, etc).
Project White, on its side, is a user interface testing framework, but to test a user interface, anyway, it implies people full time dedicated to such tasks. No need to say that test maintenance is also a problem. Imagine that a method signature changes, the corresponding tests must also be changed.
Another issue to the unit testing adoption is the learning curve for frameworks. Indeed, it is already hard to sell unit testing, but if people need a lot of time to write their first unit tests, it does not bring any help.
On the IoC and Containers, some frameworks are coming, such as Ninject, Castle Windsor, Unity. The trend is also to use IoC to wrap legacy code.
On the design side, the trends are : Domain Driven Design, Design for testability, and Test Driven Design in opposition to “classic” OO encapsulation or BDUF (Big Design Up Front).
For Isolation Frameworks, Stubs, Typemock and Rhino Mocks are raising, while Mocks over specification, Nmock and Easy Mock are failing. Remember, mocks are used to fake a system or an interface, but, nevertheless, most of the mocks framework force to use a specific design.
With this number of framework, the ideal would be to have a merge between the testing frameworks and the isolation frameworks, but it is going to be difficult. Unit testing framework have no faking capabilities while Mocks frameworks have no running capabilities.
Finally, Roy explains that the main reason why Test Driven Development fails is because of a push-back from the community : how to explain that many lines of code need to be written for the tests, before writing the code itself ?

You May Also Like…

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *