A Test Driven Culture and Agile


All the companies I have worked and consulted fall into one of two camps: those that are passionate about test driven and those think it is a nice idea for other people.  If you have a company or team that is slow to deliver, I’ll bet $1,000 they fall into the latter.

To really understand test driven development, you need to have a mental image of a ratchet gear.  Inside a ratchet wrench is a gear with a pawl (aka click) that engages the gear and prevents it from going backwards.  In other words a ratchet gear only moves forward, never back.  That is the goal of unit testing in a nutshell. In a test driven environment you build a ratchet for every piece of functionality.  Once something works, you lock in that behavior with a test case that prevents desired behaviors from going south.

There are some important cultural values I’ve noticed in the best engineering companies regarding this topic.  Here’s a few you can take to heart.

1. Unit tests are more valuable than code

If it is true that a unit test locks in behaviors and not implementations, then if you are re-engineering a system you will keep the tests and discard the old code.  Personally, I find writing code is easy.  I have no emotional attachment to a specific implementation of anything.  I fully expect it to get progressively cleaner and better.  Therefore, once I’m confident that the tests are reliable, I’ll throw out an implementation as soon as I find something better.  I am fully confident that the unit tests will ensure the new system is just fine.

2. Never refactor without solid unit tests

No manager should allow re-engineering or refactoring of code in the absence of unit tests.  This is a corollary to #1.  If you don’t have tests, then refactoring is scary business and you should avoid it until the tests cover all the expected behaviors.

3. Never fix a bug until you have an automated test that proves it exists

At one test driven company, we did test case reviews prior to allowing anyone to even work on a bug.  The art here is to drill deep into the system, find the core issue, and create the lowest level test possible.  It’s easy to build a Selenium-level test case and record the issue at the user level.  But those sorts of tests are expensive to maintain.  Also, it’s easy to put a patch on something and make everyone think you actually fixed it.

During our test case reviews, we could make sure the engineer dug to the heart of the problem before creating a fix.

4. If someone introduces a new bug, it was the fault of the previous engineer

This is a huge cultural shift and mindset.  Only the most advanced engineering organizations grok it.  Let me explain this by example.

Engineer Sally develops an algorithm to compute maximum distance between two sine waves.  She builds a unit test for a few examples and checks the code in.

A year later, Engineer Bob, optimizes the algorithm and introduces a bug.  The code is released and customers start to complain.  Whose fault is it?  Sally or Bob?  In a true TDD shop, the answer is Engineer Sally.  “What?” you ask.  Engineer Bob broke the code.  Yes, but the fact that the bug ever left Bob’s desk is Sally’s fault.  She needs to take ownership of the unit tests.  Of course Bob and Sally, as good team members, work together to fix the tests, but you get the idea.  The test cases had just as much wrong as Bob’s changes.

5. Sprint closure includes the unit tests.

When you see this happening, you know you’re working with the best engineers.  Your users will never understand this as they want functionality now.  However, what if you had been doing that for the last 5 sprints.  Now how fast would your team be moving now?  They never look back, fully confident that the ratchet is in place.

The Goal Achieved: Fast Delivery

This is where the speed comes in.  Image a case (and I’ve worked in these environments) where all system behaviors are locked in tests.  Now you have to perform a massive refactoring. There is absolutely no fear.  Your architect or lead engineer can refactor a key component, run the test suites, and check it in.  Nobody blinks an eye.

Look at it another way.  You have a pile of technical debt and no unit tests.  Who is going in there to clean it up?  Management is terrified to let that happen.  “It will take too long.” “You’ll break everything.” “Better the devils we know than the ones you’ll make.” etc.  As a result, your engineering becomes slower and slower.  That pile of technical debt becomes a hill, then a mountain.  Eventually, it is the ball and chain that prevents you from moving forward.  You start the technology decay process.  Your competitors seize the opportunities to run technical circles around your organization.  You might think I’m being mellow dramatic, but I’ve seen it happen.

You’re going to ask, “So Steve, if we write unit tests we can avoid major problems?”  Nope.  Success does not come just from having unit tests, it comes from a culture that wants to make them.



About Author


Steve works with successful software startups and tech companies throughout Silicon Valley. Most recently he has been developing content migration tools for large websites. He has a deep passion for all things software engineering, from design concepts, to team management, to final delivery.

1 Comment

  1. Let s be honest how many people have written tests that don t work, are just plain wrong or have to jump through so many hoops and mocks to get them working that they themselves become unmaintainable?