Jeremy D. Miller -- The Shade Tree Developer

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.