how to convince people to unit test?

[Robin Clark]

I am tasked with trying to convince my co-workers that they should unit test BEFORE they integration test. Our corporate culture is one where no pure unit test cases have ever been written. All repeatable testcases that are written use many objects (not just the class under test). The problem is that these testcases are very sparse, don't usually test the throughly and they break after one release because they are dependent on other objects and database contents.

The pushback that I am getting from people is as follows:

1) We don't have time to write unit test cases for methods that are not being changed (and of course there are no previously written unit test cases because we didn't have time in the last project)
2) It is quicker to write integrated tests...it saves a step
3) Writing unit test cases (with mock objects) doesn't really test the code

I am a total convert and believe that time can be saved by writing repeatable unit test cases before you even think about executing integration tests. But I am a poor salesperson and am having trouble convincing others that they will save time and have a better life by embracing unit testing.

Can you please help me by pointing me towards some really compelling evidence to convince others?

Thank you.
4)

[Jeanne Boyarsky]

Robin,
I have two thoughts on this:
1) Start by writing unit tests yourself. Try to get buy in that once a test exists, it should continue to work. This means people should agree to change tests if they change tested code. Once you get this, you can lead by example. People will start to see that it is easier to work with code that has tests.
2) Start small. Suggest writing unit tests for utility classes and simple classes that don't need mock objects. It's easier to see the benefits of testing on these.

[Jeanne Boyarsky]

Originally posted by Robin Clark:
1) We don't have time to write unit test cases for methods that are not being changed (and of course there are no previously written unit test cases because we didn't have time in the last project)
2) It is quicker to write integrated tests...it saves a step
3) Writing unit test cases (with mock objects) doesn't really test the code

I've heard of all of these when introducing people to our team process (and when introducing the process itself.)

1) Don't write unit tests for methods you aren't changing. Just write them when fixing defects or adding new functionality. One project went from 0 to 95% coverage this way.
2) It's only quicker if the code is perfect. If you write an integration test and it fails, how long does it take to fix the code and retest - 5 minutes? If a unit test fails, it only takes seconds to fix and retest. Plus the tests aren't just being written to make sure the code works. Their value as regression tests is just as (if not more) important. Writing unit tests shows what cases you thought about when writing the code. When someone else (or the future you) changes the code, they have the benefit of your explicit knowledge. And they notice they broke one of your assumptions right way rather than at integration test time.
3) That one is tougher to argue against because it is somewhat true. This is why I recommend starting to write unit tests with classes that don't use mock objects. The main purpose of the test is to check you are calling the right methods. This takes more getting used to. After your teammates have written simpler unit tests, it's easier to explain the benefits of mock objects.

[Frank Carver]

Just to echo the comments about mock objects. The use of mock objects in unit testing needs very careful handling. It's dangerously easy to make horribly fragile tests using all the mock object frameworks I have encountered, and that would damage your cause, possiibly forever.

Start with really simple input vs output tests for a few well-understood "utility" objects or methods. If at all possible, try to include a few tests which "just happen" to demonstrate unknown faults in the code under test. Aim for tests which apply to edge cases, passing nulls, empty strings, negative numbers, or anything which might stress the basic logic.

Once you have shown that such tests have a function, you can move to the strategy advised above - do your own work in a test-driven way and grow a testbase for all code which you touch. Once you have a decent size selection of robust tests, get the running of the tests into the build process so that the delivered artefacts are not built until all the tests have passed.

Any of that make sense?

[Ernest Friedman-Hill]

I've convinced people to give unit testing a try by asking them which they enjoyed better: writing code, or debugging. Nobody ever picks "debugging". Then you tell them that by writing test code, you reduce the amount of debugging you do -- you do more of something you like, and as a result can do less of something else you don't.

[Steve Fahlbusch]

Another way, assuming that defects are indeed tracked.....

Capture some history of number of defects per X.

Start doing unit tests yourself (where practical) and see if there is indeed a reduction in errors in your code. You can then use yourself as an example (without pointing the finger at anyone else).

Also what I found very useful in the teams that I run - I fine the responsible person $10 for each defect found.

[Ilja Preuss]

Originally posted by Steve Fahlbusch:

Also what I found very useful in the teams that I run - I fine the responsible person $10 for each defect found.

I'd think that this would be rather dangerous, and easy to get wrong.

What I like least about it is that it focuses on individual effor instead of team effort.

[Alexandru Popescu]

That's a very interesting topic and I've been reading all the suggestions in this thread. However, I feel like playing the devil role :-).

So, I will start by asking: can you proove to your collegues that writting unit tests will help them out? (and by "them" I mean each developer, and not the team, not the product, not the project manager, etc.). One hint in this direction was given by Ernest Friedman-Hill when saying:

write unit tests or debug

(even if I am enjoying doing either with the right balance ;-)). Can you show them that by righting an unit test they will have an easier way to fix a bug or your bugs can be reproduced only through functional/integration tests?

However, for the moment, I guess the answer to the above question is no, because otherwise you wouldn't be asking the question here. Now, you should answer yourself why cannot you proove that unit tests will help them out. And as far as I can imagine the answer would be in the following range: the code is not easily unit testable, so writting unit tests would make them work more. If this is the case then you will have much more work to perform: introduce a shift in the way your software is written so that testability becomes more simple (and this is a very long topic). The other side of the answer can be: our business logic is so little as unit tests do not pay back the effort and we prefer doing higher level functional/integration testing as this is the part that is complex enough to be tested. And in this case, I would recommend you to leave it this way, and just look into ways to improve the quality of these test so that they survive and remain valid even after a release (shameless plug: you can take a look at TestNG).

As regards some of the suggestions made in this thread, most of them will work, but sometimes will also fail (f.e. be the first one writting unit tests. You can do that, but if the code is changing too fast and the tests will start to fail a couple of times per day, people will disable them, and you will be the only one fighting with them; moreover you will be the only one to work on them and so you will have less and less time left to implementing real stuff).

I know I am not giving the kind of answer you would expect. But I am a pragmatic developer and I don't believe in silver bullets. Unit testing may proove usefull to some teams and products, but it can also be an unneeded expense on others.

cheers,

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

[Jeanne Boyarsky]

However, I feel like playing the devil role :-).

That's what makes these discussions interesting! Most people that are anti-testing aren't in this forum. So someone playing the devil role is the closest we get

Can you show them that by righting an unit test they will have an easier way to fix a bug or your bugs can be reproduced only through functional/integration tests?

As a variant of this - if I write a low level class that contains a bug and it can't reproduced through a functional/integration test, is it still a bug? I would argue yes because the code exists and can be called differently in the future. For example, suppose a method crashes when you pass in "3" and the calling code doesn't pass in "3" at the moment. Clearly something is happening that shouldn't. However it wouldn't show up in the bug list.

However, for the moment, I guess the answer to the above question is no, because otherwise you wouldn't be asking the question here. Now, you should answer yourself why cannot you proove that unit tests will help them out.

It's hard to prove things. And even if you can, you need people to feel that testing is important. This is true for unit or functional/integration testing in JUnit or TestNG. People write better tests if they buy into why testing is important and aren't just doing it because someone told them they have to.

The other side of the answer can be: our business logic is so little as unit tests do not pay back the effort and we prefer doing higher level functional/integration testing as this is the part that is complex enough to be tested.

This is tricky. Many people who don't write unit tests believe that functional/integration testing is sufficient. I certainly did four years ago.

As regards some of the suggestions made in this thread, most of them will work, but sometimes will also fail (f.e. be the first one writting unit tests.

As the person who suggested this, I meant for it as a short term measure. It is still important to get people to agree the tests should always work even if they aren't writing them yet. I actually had some success with this because it was easier to get people to agree that "tests are good and should run" than that they should write the tests. Then once some tests are in place, the benefits start to show themselves. And of course, sometimes this will fail. That's why there isn't any one answer we can give - it depends on your team.

But I am a pragmatic developer and I don't believe in silver bullets. Unit testing may proove usefull to some teams and products, but it can also be an unneeded expense on others.

Agreed. I think there are many more cases where unit testing proves useful than when it doesn't. I think it goes by product, not team though. Some things are so simple and have such a short shelf life that unit tests could be overkill. I have trouble picturing a whole team that couldn't benefit.

[Alexandru Popescu]

As a variant of this - if I write a low level class that contains a bug and it can't reproduced through a functional/integration test, is it still a bug?

Yes, it is. Unfortunately, there will always be bugs, and I really don't think there is something we can do about it :-) (not even the so called 100% test coverage will find them, because most of the time this 100% is what we can imagine to be 100%, not what real world uses as 100%).

It's hard to prove things. And even if you can, you need people to feel that testing is important. This is true for unit or functional/integration testing in JUnit or TestNG. People write better tests if they buy into why testing is important and aren't just doing it because someone told them they have to.

My point is: the developers will do something that makes their life easier. I will always fear to ask my team to do something that makes their lifes even more complex. For a team it is easier to see the benefit of functional/integration tests (if these are enough easy to be developed maintained), rather seeing the benefit of unit testing (and if we get to mocks then I am hearing their questions :-) ).

Many people who don't write unit tests believe that functional/integration testing is sufficient. I certainly did four years ago.

Frankly speaking I do like more these and I encourage teams to have at least these in place (and most of the time I can proove their importance and the fact they are paying back the effort). Still, I am not saying unit tests are not good.

As the person who suggested this, I meant for it as a short term measure. It is still important to get people to agree the tests should always work even if they aren't writing them yet. I actually had some success with this because it was easier to get people to agree that "tests are good and should run" than that they should write the tests. Then once some tests are in place, the benefits start to show themselves. And of course, sometimes this will fail. That's why there isn't any one answer we can give - it depends on your team.

Unfortunately, my experience is quite different. Under pressure, the first thing done is to disable them. And that's the end.

I think there are many more cases where unit testing proves useful than when it doesn't. I think it goes by product, not team though.

I will not argue on this, but I would encourage you to listen to Venkat Subramaniam on Pragmatic Agile Adoption]Venkat Subramaniam on Pragmatic Agile Adoption and see what I meant.

BR,

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator

[Jeanne Boyarsky]

Originally posted by Alexandru Popescu:
I will not argue on this, but I would encourage you to listen to Venkat Subramaniam on Pragmatic Agile Adoption]Venkat Subramaniam on Pragmatic Agile Adoption and see what I meant.

Interesting. What I got out of that link is that some projects are too large that they have essentially already failed and need to be broken up into smaller teams/iteration before introducing XP. He also stated it wasn't practical to do unit testing because the project was so late.

I agree that it is important to start with a smaller group when introducing change. Whether it is a single module on a big project or a smaller project. I also agree that adding unit testing to a late project only makes it later. I was thinking more about greenfield projects when I made my previous post.

[Alexandru Popescu]

I was thinking more about greenfield projects when I made my previous post.

Makes sense, but wanted this clarified for the OP. Also, my understanding of his post is that he is not working in fact on new projects ;-).

BR,

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator