You’re a TDD newbie on a project team with Jeremy, what do you do?

I was cranky the day I wrote this, can you tell?

  • DO take TDD seriously or Jeremy will ride you mercilessly persistently remind you to do so. 
  • If you think writing unit tests is hard with the project’s current approach, DO talk with Jeremy about changing the approach, or just DO IT and show Jeremy the better way later.  If it’s hard to test, it’s probably bad.
  • DO make suggestions.
  • DO write unit tests first for everything reasonable — and it’s reasonable almost everywhere.
  • PLEASE DO make a good faith effort to learn how to write testable code.  It’s a significant adjustment.  TDD is all that and the proverbial bag of chips, but it does come for free on day 1.
  • If you don’t know how to write a unit test for a task, DO ask Jeremy for help!  It’s Jeremy’s job to help you.  You’re not gonna look bad for asking for help, you’re simply making Jeremy earn his salary.
  • If nothing else DO write unit tests after you make the code work, just don’t whine to Jeremy when you find out that it’s harder to retrofit tests than it is to go test first because he will just act smug and say “I told you so.”
  • DO NOT commit code without any tests.  DO NOT get caught dead with multiple defects in code with no unit tests.  Something always leaks through no matter how good your unit tests are, but let’s at least make the testing net pretty fine. 
  • If nothing else, DO NOT say you’re done with a coding task until you’ve verified that the code does what it’s supposed to do.  I’d rather you did TDD effortlessly, but manual testing after coding beats nothing.
  • If you break the build, just FIX IT.  Jeremy doesn’t do the Shame Card or Smelly Shirt crap, but likes that soothing, little green ball in the system tray for a clean build.
  • DO learn how RhinoMocks works or DO NOT use it.  Seriously.  It’s a very powerful tool when used correctly, but it punishes folks with a shallow understanding of the tool.  Understand what it does, don’t memorize, and don’t try to copy/paste RhinoMocks code you don’t understand
  • If you don’t grok mock objects, DO ask Jeremy for alternatives.  There are other ways to do TDD.  A lot of people seem to be allergic to dynamic mock objects, so don’t ever think you’re the only person in the world who struggles with it.
  • If writing Assert.AssertSomething seems really repetitive, think or talk about a way to make the tests more declarative.

And please, please, please don’t just stare at the screen if you don’t know what to do next.  It’s okay to spike something, just come back and do it TDD as soon as you know what to do.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Nandu

    What are the alternates to using mock objects? I find them quite difficult. Any help/guidance in understanding mocks is also welcome.

    Thanks.

  • http://www.rzrsolutions.com Jon Parker

    Jeremy,

    Thanks for the insights…good to know what the more experienced look for out there…

  • Vikas Kernni

    Link title (not mine)

    I pity the fools who don’t write unit test cases
    http://www.codinghorror.com/blog/archives/000640.html

  • http://joesadowski.com joe

    “and don’t try to copy/paste RhinoMocks code you don’t understand”

    That really should apply to all code, not just RhinoMocks.

  • http://blog.donnfelker.com Donn Felker

    “If you break the build, just FIX IT. ”

    I wish developers would understand this simple one.

    Here’s one to add to the list in relation to Agile/TDD, etc.

    “Yes, it is required to add a comment when you check in code, and NO … a period is not valid.”

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @TDD Jihad,

    Be a little more reticent to use that terminology. Yes, I’ve put a pretty strong stake in the ground about TDD, but you need to look at it this way. The choice to do TDD is basically a social contract for my team. If you’re a part of the team, you abide by the social contract. You of course get a say in what that social contract is.

    Nowhere in this post do I demonize folks that aren’t adopting TDD, just exhorting my team to do so because that’s the way we’ve chosen to deliver.

    There are always worlds of jobs that don’t require TDD that you could choose instead.

  • http://www.heliosfx.com Travis

    What I would give to work with a “Jeremy”. Any “Jeremy”s out here in Ewtahh?

  • TDD Jihad

    I agree with all. BUT all i read here lately is this TDD jihad stuff. It’s becoming ‘us and them’. That’s not good.

  • Scott C

    I’m more scared of working on a team that doesn’t have beliefs similar to Jeremy’s.

    Needless to say, but I too would like to work with Jeremy — not willing to move to New York though.

  • http://www.iserializable.com Roy Osherove

    hehe :)

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    Roy,

    I think I might have been channeling too much of this->

    http://www.chucknorrisfacts.com/

    My favorites:

    Chuck Norris divides by zero
    Chuck Norris’s tears cure cancer, too bad he’s never cried

  • http://www.iserializable.com Roy Osherove

    I understand, but you sound scary, dude. And yes, angry. that can’t go down well in a team, from my experience.

    Roy.

  • http://weblogs.asp.net/astopford Andy Stopford

    Jeremy cranky pants ;-)

  • Jordan

    Jeremy, I want to work for you. If this is your cranky, then you definitely know how to communicate effectively and not aggressively.

    Seriously, those in your organization should be grateful that they have your mentoring.