JUnit Success cases

Hi Kent,

We tried using JUnit in our company, didnt work out.
We offered a prize for anyone who implemented JUnit in one of our projects, someone did, I mean started, and it just didnt stick.
Have you seen many success cases ? Im particularly interested in big corporations, which is my case... How much past experiences shows the Unit testing was really worth it ?

thanks in advance,

Hi Giselle,

When I worked for SuSE on the project YaST we used Unit Testing.
YaST isn't a java project so we obviously didn't use JUnit. We
used DejaGNU/Expect framework. The requirement was that there
should be a test case for every non-UI function. Of course this
was not met in 100% cases but it worked pretty well. We did not
strictly follow the pattern that test should be written before
the code though.

Tests were run as a part of the build process. Whether it was
worth it? Yes. Especially when one had to edit other people's
code it increased certainty that nothing was screwed.

Best regards,
Petr

I have found in the past, that many developers are reluctant to write unit tests because they don't really understand how to design their tests to reflect the tasks they have been asked to perform.
On one project for example the developers were split into four teams, of the four teams only one team consistantly produced unit tests which could be automated. The other three teams would always use the excuse that their requirements had changed and once they had adapted their code they would write the unit tests to reflect the changes. However with the delivery deadline getting closer and a lack of discipline on the developers side these tests were never written.
How have you managed to change developer's preceptions on unit testing so that they have embraced it ?
[ October 12, 2004: Message edited by: Nigel Browne ]

Originally posted by Nigel Browne:
How have you managed to change developer's preceptions on unit testing so that they have embraced it ?

Maybe last week's promotion book would offer some tips

In general, developers won't follow a practice unless 1) someone forces them to, or 2) they see the value proposition of that practice. For the obvious reasons, the latter is more likely to succeed in the long run.

Originally posted by Lasse Koskela:

In general, developers won't follow a practice unless 1) someone forces them to, or 2) they see the value proposition of that practice. For the obvious reasons, the latter is more likely to succeed in the long run.

This is my point, enforcing a large team or teams of developers to embrace a practice takes alot of time and effort. When deadlines are tight the enforcement of regulations seems to always slacken in the rush to get things completed. Project managers want to get through usability tests and start to argue that any bugs will get picked up during these tests and if the unit tests aren't in place but the functionality is, then roll on user testing.
So to get a team on board with unit testing, the second reason must be understood by the developers on the team. They must see the benefit of writing unit tests and not see it as a chore set by their boss.
I know the question can be raised that without unit tests how can you be sure that the functionality is in place?
Knowing that something is good for you and actually doing the thing that is good for you are two completely separate things and what I would like to know is how to convince developers that embracing unit testing is a good thing.

Unfortunately in my experience the unit testing adoption was decided by project management vs technical stuff discussions. In so many cases I cannot count down, the project terms/budget imposed by project management (I would say bad understood project management) didn't allow extensive usage of unit testing. Even if you can explain your team that unit testing is usefull (and the team really understand this) you cannot explain the after-hours non-recognized work (for a long period).

./pope
[ October 12, 2004: Message edited by: Ali Pope ]

Originally posted by Ali Pope:
Even if you can explain your team that unit testing is usefull (and the team really understand this) you cannot explain the after-hours non-recognized work (for a long period).

And the answer is... Don't separate unit testing from coding. If you do them both all the time, you don't need to stay late.

Originally posted by Ali Pope:
Even if you can explain your team that unit testing is usefull (and the team really understand this) you cannot explain the after-hours non-recognized work (for a long period).

Of course if the unit tests were written and passed while the code is being written, after-hours non-recognized work should not happen. This is because developers know their code does what is supposed to do (if the test are passed) when they leave the office. However the biggest reluctance to writing unit tests, has been when developers aren't sure of what to test. I don't know how many times I have heard, "There's no point in testing this function, the requirements have been changed and it wont be used anymore. If I write unit tests for everything used and unused I'll be here forever."
[ October 12, 2004: Message edited by: Nigel Browne ]

Originally posted by Lasse Koskela:

And the answer is... Don't separate unit testing from coding. If you do them both all the time, you don't need to stay late.

It would be very nice and easy to make this happen. But the planning uncover this little secret and you're doomed.

Maybe (and I hope this is true) many of you haven't met this situations and probably it is hard (in a way) to understand how it is possible. In my experience I have seen projects gone directly on the wrong direction only for assuring the terms imposed :-((.

./pope

PS: I will not continue this because it is not very related to testing ;-), more to project management.

Originally posted by Ali Pope:
It would be very nice and easy to make this happen. But the planning uncover this little secret and you're doomed.

Maybe (and I hope this is true) many of you haven't met this situations and probably it is hard (in a way) to understand how it is possible. In my experience I have seen projects gone directly on the wrong direction only for assuring the terms imposed.

I have been in situations where the deadline imposed to me has been so utterly impossible that I have more or less willingly fallen back to just pounding out code, testing as little as possible, and turning in the component just before the deadline with my fingers crossed. So far, the outcome has been mostly satisfactory (meaning that the component has worked but extending it with new functionality might be pretty much a rewrite or something similar). Also, these occasions have been mostly desperate phone calls from some other project looking for help with problems they haven't managed to solve or don't have the time/resources to solve. When you've got five days to the deadline and you're doing the job on top of your regular hours, it's not difficult to let go of the practices you know produce value.

Lasse I am unhappy to find out you have run through this process too. the stupid established deadlines !

./pope

PS: hmmm this postings are running on the wrong way

Nigel,

"There's no point in testing this function, the requirements have been changed and it wont be used anymore. If I write unit tests for everything used and unused I'll be here forever."

And, of course, if the unit tests were written and passed while the code is being written this wouldn't happen either... the tests would already be there.

Where I'm at, unit tests are mandated, and since we brought in jCoverage they're somewhat managed. We're still tweaking this, and haven't arrived at a really solid philosophy about it yet.

The biggest problem I've seen is that testing's a different discipline from business logic coding, and not all developers "switch hats" so comfortably. Some seem to enjoy it. Others do experience some discomfort when they switch contexts, and if you let them they'll slip into a pattern of coding for weeks and then going back to do the unit tests when coverage hits the lower control limit.

Second biggest problem I've seen is attitude. I know developers who just plain don't want to do it, and are happy enough when something comes along that pushes testing off the agenda. You can evangelize up to a point of diminishing returns, and then it has to come down to policy. At least, that's what we discovered. It works that way for lots of things, doesn't it?

Terry
SCEA/SCWCD/SCBCD/SCJP

Wow! That's what I call feedback !
Im happy Im not the only one experiencing issues in going for Unit Testing.
Thanks everyone !

Glad to be of help, Giselle.
Whatever happens, don't stop trying to improve on your habits

Second biggest problem I've seen is attitude. I know developers who just plain don't want to do it, and are happy enough when something comes along that pushes testing off the agenda.

Yep that's it. Many guys I've met prefer to work on a task a few days in a row without seeing any output and that starting to track back the problems. Others prefere to make their lifes a little easier and test every little thing they are writting. Others are doing a lot of effort to include possible future extensions (ignoring the KISS principle) and never getting to the end. As always the best solution is somewhere in the middle. Or should I say the best solution is the one that best fit your problem :-/.

./pope

Ali,
Once you know how to test and gain some experience in it, writing unit tests doesn't take longer than writing code and debugging it. The trick is to get to that point.

Lasse's comment reminds me of a quote someone at work says: "If you throw out your process because of deadlines, it's not really a process." I'm not sure where this quote came from originally. But it's a good measure. At the beginning, I did throw out unit testing because I was busy. On the last project (which had a tight deadline), I wrote through unit tests. And by now, I realize that it does help!

In the last of these last-minute projects I did, I didn't actually drop unit tests. I tested it manually when I got closer to the end and finally sent it back to the project needing such a beast. A couple of weeks later, I get another call asking for an additional "operation", an extra feature. Ok. No problem. The unit tests were there, I added the new ones, and returned the code -- after no manual testing at all. The reason being that I felt I didn't have the time to install two LDAP servers for manual testing and I "knew" that what I was adding did not involve contacting the servers but were all about transforming data within the local object model.

I felt a bit unsecure returning the modified code without manual testing, but I also realize I would've felt a lot less secure had I not had the unit tests to give me confidence on not breaking anything.

Jeanne said:
Once you know how to test and gain some experience in it, writing unit tests doesn't take longer than writing code and debugging it. The trick is to get to that point.

I do agree with you that writting unit tests is not a difficult task in many cases. What I have said is that I've met moments when the PM just cut down the development time pushing off the unit testing.
Moreover, because I feel, I was badly explaining myself: I do believe that unit testing is something mandatory for the success of a project. I was just presenting some scenarios (unfortunately real scenarios) in which somebody non- technical changed the way the developers team had to work. There are times when you cannot argue your boss saying: "Just do it this time, I want this contract on my desk".

./pope

Another thing to keep in mind is that applying unit tests on an existing project can be very difficult if the code is not well designed. With well designed I here mean that every unit of code (method, class, package) has a well defined responsibility and dependencies between those units are reduced to a minimum.

One of the benifits with Test Driven Development is that it forces you (or at least encourages you) to write well designed code.

/Rickard
[ October 13, 2004: Message edited by: Rickard Johansson ]

Originally posted by Giselle Dazzi:
We offered a prize for anyone who implemented JUnit in one of our projects, someone did, I mean started, and it just didnt stick.

Perhaps you should have invested into training instead of a prize?

"I do agree with you that writting unit tests is not a difficult task in many cases. What I have said is that I've met moments when the PM just cut down the development time pushing off the unit testing."

Ali, I do realize you are being the devil's advocate here. It's a good role to help understand something. I refuse to give this as an option. I insist that writing the unit tests and coding are an integral activity that can't be separated. I include both in my estimates and the code isn't done until the tests are there. Having said that, we have someone on our team that used to hold off on the tests until the end and run out of time. If the tests are left for the end, I can see how the PM could cut down time and prevent testing.

Ilja, that's a good point.

Originally posted by Jeanne Boyarsky:
Ali, I do realize you are being the devil's advocate here. It's a good role to help understand something. I refuse to give this as an option.

i've bean unmasked ).
Jeanne, one more question: your team use pure TDD (write tests, write code) or the other way around: write code, write tests (one every step)?
I must confess that till now I wasn't able to apply pure TDD in my development.

./pope

Originally posted by Rickard Johansson:
Another thing to keep in mind is that applying unit tests on an existing project can be very difficult if the code is not well designed.

One word for this: REFACTOR
[ October 14, 2004: Message edited by: Nigel Browne ]

Ali,
First of all, what I do and what my team does aren't the same. I'm the one who tries to push this stuff on the team and I do it by starting something and showing it works. Right now, I am the only one on the team who does TDD. For the last few months, I have been doing mostly TDD. While I was learning and getting used to it, I would often "forget" and go back to the other way around.

Nigel,
Yes, but you have to be very careful refactoring code without tests. It can be done, but slowly and carefully.

Congrats Jeanne! I know it is very hard to be the motor of new things into a team but the rewards are at the same size ;-). I am doing this team technical leading for about 3 years. Many times I saw me failing and started again, but when I finally succed in teaching something I feel very happy.

./pope

There are lots of reasons why any change in social structure or technique might fail to become permanent:
* It really didn't provide the benefits anticipated
* It put the spotlight on someone else's shortcomings and they put the pressure on to revert
* It worked, but the discomfort of working a new way was more important than the benefits achieved

The best antidote I know for these effects are making changes inside a like-minded community. The community can provide support, accountability (Hi, I'm Kent, I code without tests, it's been three weeks since my last deployed change with a test), ideas, encouragement, and a way of checking feelings with facts (it seems like I'm going slower now that I'm writing tests, what do you think?)

I have a chapter on community in the second edition of Extreme Programming Explained, due in stores in the middle of November.

Kent Beck
Three Rivers Institute