Your SlideShare is downloading. ×
“Can you make *any+ class work outside the
application? Can you get it to the point where you can
tinker with it, in real ...
TDD lets you take off the blindfold. Tests are a
safety net which allow us to refactor code
relentlessly without worrying ...
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)...
“One of the most useful times to write tests is
before you start programming. When you need
to add a feature, begin by wri...
“We get a double benefit from test-first
approaches; not only do they lead us to think
deeply about design at design time,...
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/...
You are not allowed to write any more of a unit
test than is sufficient to fail; and compilation
failures are failures.


...
You are not allowed to write any more
production code than is sufficient to pass the
one failing unit test.



http://butu...
“Every genuine test of a theory is an attempt
to falsify it, or to refute it. (…) Confirming
evidence should not count exc...
You can verify the resulting state of the System
Under Test (SUT), or verify the protocol of the
interactions with its col...
1. Set up the test context
2. Exercise the SUT
3. Verify the result state (or interactions).



http://www.lostechies.com/...
The Single Responsibility Principle (SRP) applied
to testing: One test should be responsible for
verifying only one thing ...
I write a failing test. Ping. You write the
necessary code to make my test pass, and
then write a new, failing test. Pong....
“Failure of the team to inspect and adapt,
especially in taking on good development
practices such as found in XP (…) can
...
“*The fact that+ design patterns makes code
easier to test is more proof that they actually
work, but this is just a side ...
“TDD forces you to (…) create better, less
coupled designs.“ _ Uncle Bob Martin




http://butunclebob.com/ArticleS.UncleB...
“*care about+ things that aren't just functional,
but easy to read, elegantly maintainable (…)
and sometimes flat-out sexy...
According to a study, people procrastinate when
asked to think in the abstract, and act in a
timely way when given concret...
http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Addison-Wesley/dp/0131495054
http://www.amazon.com/Working-Effective...
Test Driven Development/Design
Test Driven Development/Design
Test Driven Development/Design
Upcoming SlideShare
Loading in...5
×

Test Driven Development/Design

3,223

Published on

An introduction to TDD and how it relates to design and best practices.

Published in: Technology

Transcript of "Test Driven Development/Design"

  1. 1. “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
  2. 2. 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.
  3. 3. Each test is an (executable) example which tells you how some particular part of the system works.
  4. 4. 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.
  5. 5. “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
  6. 6. “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
  7. 7. You do not talk about TDD.
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. “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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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/
  16. 16. “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
  17. 17. “*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
  18. 18. “TDD forces you to (…) create better, less coupled designs.“ _ Uncle Bob Martin http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
  19. 19. “*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
  20. 20. 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
  21. 21. 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/

×