Eat, Sleep and Breathe Unit Testing/TDD/BDD [closed]

Question

A good place to start is reading blogs. Then buy the books of the people who are blogging. Some I would highly recommend:

"Uncle Bob" Martin and the guys at Object Mentor: http://blog.objectmentor.com/

P.S. get Bobs book Clean Code:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

My friend Tim Ottinger (former Object Mentor dude) http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/

The Jetbrains guys: http://www.jbrains.ca/permalink/285

I felt the need to expand on this, as everyone else seems to just want to give you their opinion of TDD and not help you on your quest to become a Jedi-Ninja. The Michael Jordan of TDD is Kent Beck. He really did write the book on it:

http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

he also blogs at:

http://www.threeriversinstitute.org/blog/?p=29

other "famous" supporters of TDD include:

• Tim Bray
• Martin Fowler
• Ward Cunningham

All are great people to follow. You should also consider attending some conferences like Agile 2010, or Software Craftsmanship (this year they were held at the same time in Chicago)

I don't like it when people say "Practice X is never bad; if it doesn't work, you're not doing it right." Sorry, it has the same feel as any other over-zealous religious dogma. I don't buy it.

I agree with those folks who say that the best solution your time and money can afford should be the goal.

Anyone who objects to TDD should not automatically be accused of disregarding quality. ("So when did you stop beating your wife?") The fact is that software has bugs in it, and the cost of eliminating all of them has to be weighed against the benefit.

The same holds true in manufacturing. Tolerances on dimensions and finishes on surfaces are not all the same, because sometimes a close tolerance and a mirror finish aren't warranted.

Yes, I write unit tests, although not often before I write the class. I've seen the effect of tests on design. I measure and watch code coverage. If I find that my coverage isn't acceptable, I write more tests. I understand the benefit of a safety net of unit tests for refactoring. I follow those practices even when I'm working alone, because I've experienced the benefits first-hand. I get it.

But I'd look askance at any teammate that started bugging me about "eating, sleeping, and breathing unit testing and TDD."

My manager says that the only way that will get me a promotion is if I can get the team to TDD/BDD.

Ever think that maybe this makes you sound like a suck-up? Have you found that your nagging has alienated the rest of your team?

This response might lose me a few reputation points, but it had to be said.

I think a better approach would be to practice it yourself and let others see the benefit. Lead by example. It'll be far more persuasive than running your mouth.

Geez, Grails has test generation built-in. If you're working on a team that uses Grails, how much more selling is needed?

Best practice IMHO: Do what is practical and not just because it is a process. Don't forget what the goal of writing applications is, and in the business world, it isn't writing tests. Don't get me wrong, they have their place, but that shouldn't be the goal.

Find someone that has been doing TDD/BDD and pair program with them.

Metrics are, IMHO, the best way to get from here to there. Keep track of how well your code is covered, keep deltas of code complexity for every commit, use test-runners that watch your code for changes and constantly re-run the corresponding tests. Never let test lengths get above a few lines, so that all your tools work well. And I'd recommend once a month, take a day off to run your code through a mutation tester. That day should be dedicated to writing tests only. All of this stuff will bring you pain if you're not already doing good TDD. Learn from the pain, and in no time at all, you'll be doing it right.

And never lose sight of what the tests are for: To describe desired behavior. They are your executable specification. (This is also why I like Cucumber; now you can get your PHB to write your tests for you! Well, maybe not quite that good, but it's close!)