I am a big proponent of unit test and test first development methodology or TDD, however from my experience working at multiple companies I have often encountered a lot of resistance to this approach of development. Before I make my recommendations on how you can counter resistance to unit testing, let me start by reviewing some of the key issues I have encountered in my various consulting and non-consulting engagements.
- Time constraints – This is the number one culprit and needs no explaining. I have often seen leadership balk at the estimates given if the software were written with unit tests, regardless of if they are written in a TDD methodology or not.
- All developers are made equal – We don’t live in a utopian development world and not all developers are made equal or priced equal. When you look at the 24/7-development model in place across the globe today, rarely are people hired because they know how to write good unit tests although they should.
- Culture – Often developers that develop the software are not the ones that are tasked with its maintenance, and most organizations just want things done fast for that pie in the sky leading to this very important aspect of development getting ignored up until maintenance becomes an issue.
- It’s too hard – When unit testing is ignored in the early phases of development it generally leads to the issue of it’s just too hard to write unit test for legacy code. Developers want to write unit tests but the code often has too many dependencies to execute in a timely manner.
- Number of tools and methodologies – There are tons of tools out there and so many methodologies that resistance from an existing functional test team is bound to be a problem. Learning and adopting new development and test techniques is very hard for people and generally people always like to go where they are comfortable.
If the picture is so dark, how do we get good quality software?
- Make compromises not in quality but in scope – Don’t develop features that need 15-20 developers coding for two months (personal experience) it only leads to sleepless nights and stress for all the people involved. Also have realistic expectations in terms of code coverage.
- Plan for Quality – Identify and communicate your quality goals to your development team early. If you start your product development using tools like FxCop, Re-Sharper, etc. and techniques like TDD can reduce the burden of bringing your code to higher quality sooner. Also plan if UI automation will be needed. It might help to advice your development teams to use automation id so UI automation can be achieved much more easily.
- Breakdown Work – Break down the work into small functional units where possible so that it is easier to develop, test and maintain (I think it’s always possible to break down work). Once broken down unit test or TDD, which once was considered an impediment, can actually become an enabler for high quality code and in many cases unit test might also help reduce the overall development time by shortening the time required to test and stabilize.
- Tools – Pick the set of tools that are best suited to your development and test environment first, socialize the tools and learning required to be proficient at them before making it a standard for your development teams. This is especially true of development teams where the team size is large and often distributed. Frameworks like TypeMock & pex and moles can help you get coverage and effectively mock dependencies in your legacy code.
- Continued investment in training – Continue to invest in people conduct workshops and make people excited about the new development techniques rather than forcing or policing what everyone does. I often see key people in a development team just spending their time ensuring quality of code that everyone else is delivering, not productive by my standards.
Principal Software Development Engineer