JUnit vs. IDE debuggers : question for Mr. Hunt and Mr. Thomas

[Dave Knipp]

Hi,
I was curious how effective you have found junit on past projects. Have you found it to be very valuable or just a waste of time...
It seems to me that junit can be overkill in some situations, but can help to debug most problems and show you where your code is working differently than you thought it was. But when so many ide's these days have awesome debuggers than is junit really still as valuable?
I'd be curious to see what you think.
Thanks for any response,
Dave

[Ilja Preuss]

Originally posted by Dave Knipp:
But when so many ide's these days have awesome debuggers than is junit really still as valuable?

Well, many IDE's also have awesome JUnit support, so why would you want to spend time in the debugger?
Also, if you have an extensive suite of JUnit tests, you can press a button and a few seconds later know wether your last change to the code broke anything. Try to do that with a debugger...

[Dave Thomas]

Interesting question.
JUnit and debuggers really solve different problems. Unit tests stop problems arising, while debuggers are used once they have arisen.
When you write unit tests as you go along, what you're doing is trying our your code 5 lines at a time. If a test fails, the problem will lie in the code you've just written (9 times out of 10) so finding it will likely involve doing nothing more complicated tham eyeballing your editor buffer, slapping your forehead, and fixing something obvious.
If you don't do that kind of testing, then bugs lie hidden in your code for weeks. When they finally appear, they could be in stuff you (or someone else) wrote a long time ago, and tracking them down is time consuming and expensive. That's when you crank up the debugger.
There are two more issues. First, unit testing gives you a safety net for your code. Because the tests are always there, and because you run them all frequently, you're always in a position to know that nothing has been broken by new work. This is important. Even in well-designed systems, it's possible for newly added functionality to interefere with existing code. With unit tests in place, you can speot this when it happens, not when your customers phone up.
Second (and to my mind, probably the most important point), unit tests are far more than just a testing tool. By thinking about testing as you write the code, you actually end up writing far better designed code (at least I do). Making your code testable also makes it less coupled and more granular.

Cheers

Dave

[Dave Knipp]

Very good points.
I agree that unit testing is slightly different than debugging. It's all about when the errors arise, like Dave said. I can see the benefit to unit testing, but i guess there is the age old question about the time it takes to test vs. the time it takes to debug your code later.
I guess the best decision is to go with unit testing for really large projects with multiple developers working on the same code base.
Do you think a small personal project requires unit testing? Seems a little overboard, but i guess if you're a purist than you may as well go for it
Regards,
Dave

[Lasse Koskela]

Originally posted by Dave Knipp:
Do you think a small personal project requires unit testing? Seems a little overboard, but i guess if you're a purist than you may as well go for it

Why do you think it would go overboard? Seriously.

[Ernest Friedman-Hill]

Debugging takes lots of time. Think about it: when an application crashes, you don't know why. It could be anything. It takes an unbounded amount of time to find a bug. Sometimes it takes minutes; sometimes it takes days.
When you're writing a test, you know exactly what you're testing, and why. It therefore takes very little time to write tests. It takes zero time to run them -- as Lasse said, many IDEs have excellent JUnit support. And every time you run a test, you confirm that something still works the way you believe it should.
As an added bonus, writing tests forces you to write testable code -- and testable code is cleaner, easier to understand, and easier to maintain.

[Lasse Koskela]

In fact, I just wrote a little piece of code that I posted in a thread in the EJB forum which I wrote unit tests for without thinking about it for a second. I'm sure I could've spared some minutes by leaving the unit test class unwritten but I'm also sure that I would save at least that amount of time later on if the small class I wrote breaks even once.
The guys who sell Clover, a commercial code coverage tool, had a nice slogan once:
You'll recover the license cost even if you find just 1 defect with our product
It's true, you know.
[ February 20, 2004: Message edited by: Lasse Koskela ]

[Andy Hunt]

The real problem is that debugging time can quickly become non-linear. That is, as the project progresses debugging time can start to take a *lot* longer because of all the interdependencies of various bits and pieces of the project.
By unit testing as you go, you've got some assurance that what you think is workign really IS working. It becomes much harder for the code to "surprise" you. By simply debugging isolated bugs as you find them, you really don't have any assurances -- or any confidence -- at all.
Debugging is "road side repair". It's the AAA of programming. Unit testing is a construction technique. It's building a car that's far less likely to break down, period.
AND IT DOESN'T TAKE LONGER.
Let me repeat that.
IT IS FASTER TO DELIVER WORKING CODE WITH UNIT TESTS THAN WITHOUT.
Thanks for a fun week, all.

[Lasse Koskela]

Originally posted by Andy Hunt:
Thanks for a fun week, all.

You too. It's been helpful hearing what you guys have to say