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
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.
write unit tests or debug
However, I feel like playing the devil role :-).
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.
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.
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.
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.
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?
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.
Many people who don't write unit tests believe that functional/integration testing is sufficient. I certainly did four years ago.
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.
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.
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.
I was thinking more about greenfield projects when I made my previous post.