If you’ve been coding in Java for awhile, you know how to write a method to test equality. Why write tests for something you can code in your sleep? Because, as Jeff Langr points out, you’ve probably made plenty of dumb mistakes in your career, either while asleep or while wide awake. It’s simpler and safer to just think of tests as specifications that you always have to code.
Crafting Java with Test-Driven Development, Part 2: Testing Equality
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I like the idea behind test driven development and use it myself as much as possible, but in talking to other Java developers I have found something interesting.
Many Java Project managers think that test driven development means that peer based code review is unnecessary. I hear the same argument “I don’t care what happens behind the methods as long as it is passes the test.”
I am surprised everytime I hear this, which has been from 4 different development managers from 2 different companies. I’m also surprised by how strongly they have felt about the TDD end all ability to solve code problems.
I am not a purist, but having been in the position of having to maintain big application for a financial company I see more problem result for badly written code, then code that has a bug or two that maybe a testcase would have caught.
Anyway I was just wondering if other people have had the same expirence, and how they feel.
Edited 2006-01-23 00:23
In a true TDD environment, you write the tests first, and then code up the class against that test case until it passes. Of course bugs can still slip by if the test isn’t properly coded, but once you get the hang of it more bugs are caught this way. More time consuming? Yes, but in the end it eliminates time down the line that would be spent debugging an issue once it reaches production. In short, always write your tests first, then code against them.
I agree with your post, but do you feel TDD is a complete replacement for peer code review?
– At my site it’s hard to get mgmt commitment because TDD code takes longer to write the initial version.
– The programmers that currently write Bad code don’t want to do the extra work they can currently skip, so they won’t switch to TDD either.
– You’re lucky, as are your customers, you can use TDD.
My personal experience of TDD code is that once you have gotten over the initial hump, it’s a mindset which you carry with you. The code you write after that point is going to be TDD.
If your management cannot allow sufficient time for your programming staff to get TDD into their heads, then you should get new management which can see a little further along the quality track.