Unit testing newbie team needs to unit test

Question

I'm working with a new team that has historically not done ANY unit testing. My goal is for the team to eventually employ TDD (Test Driven Development) as their natural process. But since TDD is such a radical mind shift for a non-unit testing team I thought I would just start off with writing unit tests after coding.

Has anyone been in a similar situation? What's an effective way to get a team to be comfortable with TDD when they've not done any unit testing? Does it make sense to do this in a couple of steps? Or should we dive right in and face all the growing pains at once??

EDIT

Just for clarification, there is no one on the team (other than myself) who has ANY unit testing exposure/experience. And we are planning on using the unit testing functionality built into Visual Studio.

Answer 1

Practice on existing bugs/defects.

This is a really tough situation. I've never gone all the way to TDD from nothing before, but in my experience, getting a team to go from no unit tests to proactively writing them has been a very "one step at a time" approach.

First, get them comfortable writing unit tests and knowing really what they are and their benefits. For my teams, it's been best to write unit tests for existing bugs. Current bugs in systems have two things that you need to teach people to write unit tests well:

1. an expected precondition and postcondition
2. an outcome that currently is not what is expected and violates that precondition/postcondition

This gives members very concrete practice examples. They can write a test before they fix the bug, so that it fails. Then, they can fix the code so that it passes, and fixes the bug. Once they're comfortable with this, then you can get them the rest of the way so that they can write unit tests with no code up-front and then write new code to get their tests to pass.

I think the trick is to give them something to practice on where there are clear method pre/post-conditions. If requirements for methods are fuzzy, it's hard for even experienced TDD people to know exactly where to start. Take it a step at time and you'll get there. Good luck!

Answer 2

I've managed to convince my whole company to switch to TDD. It wasn't easy, but it was well worth the effort: the quality of the code went up after the transition, and now nobody imagines going back to the horrible, cowboy coding times.

1. Explain, explain, explain. You don't want your team to write tests. You want your team to want to write tests. This means that they should fully understand why they should be doing it, what are the benefits, and how this will make their job much easier. Red, Green, Refactor, writing a regression test as proof that a bug has been fixed, etc. You have to convince them the whole thing makes sense before you ask them to write any code.

2. Go for the real thing (first tests, then code). Writing tests after the code hardly makes any sense, as you will never know if they actually work (and people do write buggy test cases). My intuition is that the amount of effort you need to go from no tests to tests first is much less than what you need to go form no tests through code first to tests first, so you may as well skip the middle step.

3. Start with regression tests. These are pretty simple to understand, and they give instant gratification. Of course, this assumes that the code is properly modularized and easily testable. If not, skip this step.

4. Take baby steps. TDD takes some time to get used and may be frustrating at first. Try to introduce testing in a brand new project or component, ideally: something not very important. You want to avoid at all costs the situation when there's something really important to be done really quickly and the programmers feel that TDD is getting in the way.

5. When the team starts being comfortable, have all new functionality written in a TDD manner. This depends on the size of your project, but after some time you should get a pretty good coverage, with only some legacy parts of your project written in the old way.

6. By this point, the team should already understand and embrace TDD, and the legacy (non TDD) stuff should be considered difficult and annoying to work with. Get it refactored: most pople will do it with pleasure.

Some other important points:

• Make sure you are using the best testing framework available. It will be much harder to convince people to do TDD if they have to interact with a library that is poorly written.

• Make sure the tests are easy to run and don't take to much time to finish (or cheat, for example by using an in-memory db for the tests).

• Setup some continuous integration software, so that broken tests are found immediately.

Answer 3

One way to get comfortable with TDD is to write integration tests first. Introduce test seams and true unit tests later.

The problem with writing unit-tests after coding is that the code may not necessarily be well-designed to be testable. You may need to do some refactoring or maybe re-design to introduce the test seams. But how can you refactor or re-design safely if you have no test coverage of any kind?

Integration tests can give you that coverage initially. Every time you have a regression or a production issue, fix it in the code and cover that code with a test. Once you have enough of a safety net provided by such tests, you can introduce unit tests of more finely-grained, isolated components and/or classes of your system.

Answer 4

TDD is very difficult to implement and isn't always the best option for every development team. In my previous job, the team was heavily focused on TDD. Our development model was entirely TDD using the agile development approach.Testing was done through Visual Studio unit tests.

If a developer didn't write any unit tests for his/her feature they'd be in trouble with the technical lead. Furthermore if anyone check-in a broken build or any unit tests, the developer would need to fix all issues and add a $1 to the team money jar.

Answer 5

Just a small thing to add, visualize the process. Make the continous integration run tests automatically and check for code coverage. List the most complete tested modules on some startpage that everyone can see. That should get the team competition going.

Answer 6

I went from no JUnit experience straight to TDD, and the experience made the value of TDD unmistakably apparent. I have become so thankful for the unit tests that I quickly became an an evangelist for the approach

Answer 7

I've been on teams that didn't do any unit testing but it was introduced and has become almost common to have some tests now. I would suggest exploring how well does your team understand the basics of unit testing as well as what tools are you wanting to bring in here?

In my case it was bringing in nUnit for some .Net code that was a mix of business logic, user interface, and back-end functionality. I would suggest seeing if there are some people that are more willin to want to get to it more than others so that a couple of people on the team get it and it can spread a bit better than the flip side where you try to get everyone to jump in on this. By getting some to do it well first, this enables some cross-training so that those that pick it up can be tested as to how well can they teach it to someone else.

Another point is to consider bringing in those that have more expertise to try to show this off to some extent. Thoughtworks was brought in where I work to show us some stuff that some of it did get widely adopted and other parts not so much, but I think that would be true in most places.