• Save
Test Driven Development/Design
Upcoming SlideShare
Loading in...5

Test Driven Development/Design



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

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



Total Views
Views on SlideShare
Embed Views



8 Embeds 410

http://iridescence.no 343
http://www.iridescence.no 51
http://www.slideshare.net 11
http://static.slideshare.net 1 1
http://www.mefeedia.com 1
http://translate.googleusercontent.com 1
http://faculty915.rssing.com 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Test Driven Development/Design Test Driven Development/Design Presentation Transcript

  • “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/