Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Sep 02, 2010 — Enterprise Agile Planning expert

Agile Developer-Testing Myths

Enterprise Agile Planning


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).

Top Developer Testing Myths

  1. I don’t have time to test
  2. The code is simple / It’s a small change / I’m too smart to need to test
  3. There is all this legacy code, it’s too hard to test now
  4. 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.

The post Agile Developer-Testing Myths appeared first on VersionOne Blog.


More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us