“Can you make *any+ class work outside the
application? Can you get it to the point where you can
tinker with it, in real time, build it alone in less than a
second, and add tests to find out what it really does in
certain situations? (…) That's where we are in the
industry now (…) Best practices have gotten a whole
lot better in the last five years.” _ Michael Feathers
http://www.artima.com/weblogs/viewpost.jsp?thread=42486

TDD lets you take off the blindfold. Tests are a
safety net which allow us to refactor code
relentlessly without worrying about accidentally
breaking stuff.

Each test is an (executable) example which
tells you how some particular part of the
system works.

When you have tests that both document how
your code works and verifies that it does work,
you’ll spend a lot less (or no) time debugging.

“One of the most useful times to write tests is
before you start programming. When you need
to add a feature, begin by writing the test. (…)
By writing the test you are asking yourself
what needs to be done.” _ Martin Fowler
http://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-
Technology/dp/0201485672/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1233235687
&sr=8-1

“We get a double benefit from test-first
approaches; not only do they lead us to think
deeply about design at design time, but their
legacy is a test suite that documents and
supports ongoing development of the system.”
_ Jim Webber
http://jim.webber.name/2009/01/30/83fba2cc-d1a5-4271-86a4-55e7f6b51c06.aspx

You do not talk about TDD.

You are not allowed to write any production
code unless it is to make a failing unit test
pass.
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

You are not allowed to write any more of a unit
test than is sufficient to fail; and compilation
failures are failures.
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

You are not allowed to write any more
production code than is sufficient to pass the
one failing unit test.
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

“Every genuine test of a theory is an attempt
to falsify it, or to refute it. (…) Confirming
evidence should not count except when (..) it
can be presented as a serious but unsuccessful
attempt to falsify [a] theory.” _ Sir Karl Popper
http://iridescence.no/post/Testability-is-Falsifiability.aspx

You can verify the resulting state of the System
Under Test (SUT), or verify the protocol of the
interactions with its collaborators.
http://benpryor.com/blog/2007/01/16/state-based-vs-interaction-based-unit-testing/
http://www.infoq.com/news/2009/01/classic-mockist-tdd
http://www.natpryce.com/articles/000342.html

1. Set up the test context
2. Exercise the SUT
3. Verify the result state (or interactions).
http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/07/24/arrange-act-assert-and-bdd-specifications.aspx

The Single Responsibility Principle (SRP) applied
to testing: One test should be responsible for
verifying only one thing about the SUT. Each test
should have only one reason to fail.
http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html
http://www.ayende.com/Blog/archive/2007/08/05/What-is-one-assert.aspx

I write a failing test. Ping. You write the
necessary code to make my test pass, and
then write a new, failing test. Pong. I write
the necessary code to pass your test. Rinse
and repeat.
http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=9101
http://xprogramming.com/blog/2009/01/28/pair-programming-how-important-is-it/

“Failure of the team to inspect and adapt,
especially in taking on good development
practices such as found in XP (…) can
DISABLE Scrum “ _ Ron Jeffries
http://www.scrummaster.com.au/Article.mvc/detail/48

“*The fact that+ design patterns makes code
easier to test is more proof that they actually
work, but this is just a side effect of the more
primary issue: these patterns make
programming easier... period.“ _ Scott Bellware
http://iridescence.no/post/Unit-Testing-Gives-Merit-to-Design-Patterns.aspx

“TDD forces you to (…) create better, less
coupled designs.“ _ Uncle Bob Martin
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

“*care about+ things that aren't just functional,
but easy to read, elegantly maintainable (…)
and sometimes flat-out sexy. A passion for
aesthetics can mean the difference between
code that others enjoy working on vs. code
that's stressful to look at.” _ Kathy Sierra
http://headrush.typepad.com/creating_passionate_users/2006/03/code_like_a_gir.html

According to a study, people procrastinate when
asked to think in the abstract, and act in a
timely way when given concrete tasks.
http://www.economist.com/science/displaystory.cfm?story_id=12971028
http://twitter.com/mfeathers/statuses/1148828932

http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Addison-Wesley/dp/0131495054
http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530/
http://www.amazon.com/gp/product/0321125215/