Posted/Updated on: Wednesday, June 16 2010

Selling Developer-Level Testing

By Jim Holmes


 [Note: I’m very biased to Test Driven Development approaches, but you can use the approaches in this article for pitching any developer-level testing, be it writing tests first or writing tests after. Get writing some tests. ANY (good) tests. Now!]

You’ve come back from some conference or user group meeting and now you’re all fired up about getting rolling with an exciting, empowering, productive way of developing software after hearing a few talks about Test Driven Development (TDD). You’ve sat in some talks and seen great walkthroughs, you may even have attended a hands-on workshop. The metaphorical light bulb has exploded in to blinding illumination over your head. Now it’s time to get TDD in place at your project starting tomorrow. Or sooner!
Hold yer horses, Tex. If you want to be successful in your efforts to implement developer-level testing you need to back up a pace and do some groundwork before you charge that hill.
Any form of developer-level testing[1], be it occasionally writing tests after you develop your code, using TDD to evolve your design and features, or moving in to full-blown Behavior Driven Development (BDD), has tremendous value for your software projects, but you have to be realistic and pragmatic in how you approach getting your team, management, and stakeholders on board. You’re doomed to failure in the short term if you don’t acknowledge the substantial initial friction your team will see, and you’re doomed to long-term failure if you can’t lay out the impacts to your delivery schedules as you move forward.
Making a successful pitch for fundamentally changing how your team does its work requires you to effectively present pros and cons of developer-level testing in a number of different areas. At a minimum, you’ll need to cover
  • Existing blocks to developer-level testing such as current architecture and team skills
  • Impacts to current delivery schedule
  • Refuting common arguments against developer-level
  • Clearly laying out the value proposition and benefits of developer-level testing
You have to present an honest, accurate set of pros and cons for all these as you make your case for moving forward. Your team, management, and stakeholders will sense attempts to gloss over negative impacts and you’ll lose your moral position as an honest advocate, damaging not only your attempt to implement testing now, but also dealing with any other future difficulties.
Start off by looking at your current environment so you can get a picture of roadblocks you’ll need to overcome. Dive in to your current codebase and see how testable it is right now. A number of well-respected metrics can help you get a good idea:
  • Cyclomatic Complexity indicates how convoluted and hard to test your code is.
  • Coupling reflects how many dependencies exist to and from a component. Very high coupling will increase the difficulty of your testing.
  • High lines of code likely indicate methods and classes with mixed concerns. Mixed concerns means you’ll be writing more tests than you might otherwise – and the system will be harder to modify.
Explore these issues with the Metrics plugin for Reflector, or the commercial NDepend. Look to Simian to help identify areas of duplication in your software.  Tools like these quickly generate reports and data to help you understand the overall state of your codebase.
Next, look through your codebase to see if you’re using a lot of static classes and whether you’re programming to implementations or interfaces. Lots of calls to static classes or methods, or using concrete classes instead of interfaces, limits your ability to stub or mock those dependencies to make your code more testable. Using implementations over interfaces also makes your system more tightly coupled to the concrete classes, cutting your flexibility to change the system.
These metrics will give you an idea of how hard it will be to begin writing tests as you do more work on your codebase. This information may also inform your next major area to cover: the skill level of your team.
Moving to writing developer-level tests, regardless of whether you’re writing tests first or after, means you’ll need to develop new skills in your team. Your analysis of the codebase may point out weak areas in your team’s general development skills as well: perhaps your team doesn’t understand how to code to interfaces, or doesn’t understand the impact of long methods with tight coupling and lots of nested “if” statements.
The team’s skill level is critical to the success (or failure) of moving to testing. You may need to spend time shoring up basic software engineering fundamentals. You’ll need to spend time getting your team intimately familiar with new frameworks (unit tests, mocking) and fundamental software engineering skills (SOLID design principles, refactoring, etc.). You may run into monetary costs too as you explore tools such as Team City’s build server or productivity tools like CodeRush and ReSharper.
While much of software development is about compromise on many levels (budget, schedule, politics, etc.), building your team’s skill level is one area you have to be prepared to go to the mattresses for. Your team will need to change how they work. Your team will have to learn new things. Your team will need time to get productive with new methodologies and tools. You absolutely need to include time for this on the schedule. You can’t expect to have a productive, engaged team if you’re expecting them to get 40 hours of coding done, then go home and spend their own time getting productive in these areas. Get this critical time on the schedule and in everyone’s face via lunch and learns, pairing sessions, and if the budget will support it by bringing in outside experts to help you get up to speed.
With a clear picture of the state of your codebase and team's development skills, now you can  approach the issue where the rubber meets the asphalt: impact on schedule.  Be honest with yourself and everyone involved in the project: this skill building will, initially, slow down your pace of delivery. Admit it: you’ll be spending time building new skills, refactoring parts of your existing codebase so that you can write tests as you move forward, and you’ll be spending time writing tests instead of writing features.
How much impact will there be to the schedule? In the infamous words of software architects around the world, “It depends.” You could spend weeks or months doing in-depth functional point and all sorts of other analyses, and that time would likely be wasted. Your best option is to simply use some common sense with an initial rough estimate, then refine that estimate as you proceed with your project and get some concrete evidence based on your progress. Make sure you’re being clear to your project’s sponsors about these estimates, and that you’ll be refining impacts as you gain experience.
Now you’ve got an idea of where you’re starting from, what tools and skills you’ll need to build, and a rough idea of the impacts to your work.  It’s time to start making your pitch to your team and project leadership. You’ll need to focus on selling the business value proposition of testing while refuting some common objections to developer-level testing. There are a number of great case studies based on hard, empirical metrics on the benefits of developer-level testing. Use these to help you make your case, but always be honest about the tradeoffs.
Some higher-level objections you might run in to include “Testing is QA’s job!” or “Developers should be writing features, not tests!” Both these are valid arguments, but you can use a little debating judo and flip those arguments around.
Your QA testers are (hopefully!) highly qualified, experienced folks brought on to the team to use those skills as effectively as possible. Simple data entry or navigation tests aren’t effective uses of their time. Your developer-level tests free QA from repetitive testing of things like data entry or navigation, and instead empower them to use those skills in exploratory testing of more difficult, complex areas of your system.
The perception of developers losing feature writing time while writing tests is an oft-raised objection to developer-level testing. You can flip this around from to a value proposition by pointing to the impact of previous defects in your organization. Gather up whatever evidence you can relating to the amount of time your team has spent fixing bugs found in traditional testing phases, or worse yet, those bugs which have escaped to be found by customers.
Follow that up with a pitch laying out the business value your testing initiative will bring: over time you’ll be able to more quickly change the existing codebase without fear of regressions popping up. Perhaps you’re spending extraordinary amounts of time “hardening” or testing your application before releases. Developer level testing will help you cut that amount of time, enabling you to spend more time writing features for each release. Moreover, your organization will see the overall number of defects decrease – and that means less time fixing bugs and more time delivering features.
Finally, and to my mind the most important aspect: your developers will be able to make changes to the codebase without fear, confident that the ever-growing suite of tests will catch any unintended side effects. Your team will be able to focus on adding new value to the system instead of chasing down regression bugs. You’ll see faster delivery of features and enhancements, too, as your test environment continues to improve.
[1] In this article I refer to “developer-level” testing. I’m using this term to cover unit and integration tests written in software by the developer during the software development cycle. Developer-level tests are different from tests which your quality control testers might automate or run manually.
--
Father. Husband. Geek. Veteran. Around 25 years IT experience. Co-author of “Windows Developer Power Tools.” Coffee Roaster. MVP for C#. Chief Cat Herder of the CodeMash Conference. Liked 5th grade so much he did it twice. One-time setter, middle blocker, and weakside hitter. Blogger (http://FrazzledDad.com). Quality Lead at Telligent, makers of neat social software. Big fan of naps.