This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Agile Developer-Testing Myths
This is not about agility, this is about acting responsibly. Developers – stop making excuses not to test. Managers / Product Owners – stop accepting myths about why testing isn’t happening. With that in mind, I present you the top agile development testing myths (some of which I have even said).
- I don’t have time to test
- The code is simple / It’s a small change / I’m too smart to need to test
- There is all this legacy code, it’s too hard to test now
- That’s certain person’s code, I don’t want to touch it
I don’t have time to test
The simple fact is that not having unit tests will end up taking you more time over the duration of a project. Let me give you an example:
I’m working on some relatively simple code – get data from one source, massage it, and send it to another data source. The data will be about a system that can have say 8 assets. Additionally the first source might have references to a second location to pull data from. In summary:
- Pull data from up to 2 sources for up to 8 assets (feel free to think objects)
- Massage data
- Write data
Simple enough. Surely I could write that code and have it be correct relatively easily.
Here is the kicker – when it is run, it runs against a large dataset. It will take anywhere from an hour to two hours to complete. It might run for 1 hour 59 minutes and then blow up. Our goal is to deliver usable software, not 99% usable software. Unit tests give me feedback substantially faster and allow me to save time finding problems.
Let’s say one bug is found after a modest 60-minute run. How many tests could I have written and had executing while I built the software that then provides a safety net for me going forward?
Writing unit tests does take time, no argument there. But over the duration of a project, unless the development team is writing bug-free code, having unit tests will save you a substantial amount of time during the implementation of your product.
The code is simple / It’s a small change / I’m too smart to need to test
A good buddy of mine, Chris Berry (co-author of ATOMServer), said it best – I’m not smart enough to not write tests. A month after you write the code, do you think you will remember your intent with a function? You won’t, but your tests will. Find a bug? Write a test that proves its fixed.
Your agile team members who focus more on the overall quality, usability, and edge cases of the product are not your breathing debugger. Even small changes can have unplanned consequences. Value the time of your teammates and don’t make them find out that the simple change that didn’t need a test caused the rest of the application to behave strangely.
There is all this legacy code, it’s too hard to test now
Read Michael Feathers’ book Working Effectively with Legacy Code. You’ve heard it before but it’s true…start small and write just one test. Feel the power that one test gives you. When you have time or when you are fixing / enhancing existing code, only do it with tests. After some time, the inertia of your tests will start taking over the legacy code, exposing problem areas before they are found, and walking you down refactoring lane. Its a fun walk, enjoy it.
That’s certain person’s code, I’m not sure about it
Back in my ‘dark ages’ of development (pre-testing), I quickly became the specialist on the majority of my code. Actually, the whole team became specialists on their code. Sure, others could work on it, but time is always critical and businesses need quick turnarounds. For time-efficiency, we would all continue to work on our own code. Guess what? That became old and boring very fast.
Write tests so others can understand your code and the intent of your code quickly. Having tests lowers the entry for others to take up and support your code; allowing you to move onto other, more exciting work. You know what is pretty awesome? Agile teams that can actually work on the whole code base. It is not only liberating for the delivery team, it is liberating for the product owner and ultimately for the customer.
These are the most common myths around developer testing I hear. Have some to add? Let’s hear them and bust some more.
Want to learn more about agile testing? Check out The Agile Tester White Paper.