Your SlideShare is downloading. ×
0
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
TDD Painkillers
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

TDD Painkillers

4,074

Published on

Presentation given at DDD Dublin on 9th October 2010. Covers common issues with TDD and ways to over come them.

Presentation given at DDD Dublin on 9th October 2010. Covers common issues with TDD and ways to over come them.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,074
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. C# TDD Painkillers<br />@Ben_Hall<br />Ben@BenHall.me.uk<br />Blog.BenHall.me.uk<br />CodeBetter.com/blogs/BenHall<br />http://www.flickr.com/photos/pinksherbet/4004791663/<br />
  • 2. London based ASP.net MVPWeb Developer @ 7digital.com <br />Open Source Developer<br />WHO AM I?<br />Co-Author <br />Testing ASP.net Web Applications<br />www.testingaspnet.com<br />
  • 3. You<br />Test Design<br />App Design<br />
  • 4. http://www.flickr.com/photos/chiotsrun/4115059294/sizes/l/<br />
  • 5. Test Design<br />http://www.flickr.com/photos/nyuhuhuu/4442144329/<br />
  • 6. TDD doesn’t mean NUnit<br />
  • 7. TDD is about learning<br />
  • 8. TDD is about validating the unknowns<br />Proving your own assumptions<br />
  • 9. Fundamentally the biggest TDD painkiller is not doing TDD<br />
  • 10. That’s why we have a QA department<br />
  • 11. Ideally Pairing<br />Developer writing the testDeveloper writing the implementation<br />
  • 12. <ul><li>Do enough just to get the test to pass
  • 13. Write more tests to express more behaviour
  • 14. Wouldn’t it be cool if...
  • 15. Loose focus
  • 16. Takes longer to achieve what you wanted to deliver</li></ul>Do the simplest thing possible.“First make it work, then make it right”<br />
  • 17. “TDD like you meant it”<br />
  • 18. http://www.flickr.com/photos/peasap/1625639532/sizes/l/<br />Spike<br />
  • 19. IRB (Ruby)<br />Want rapid feedback<br />Allows you to learn quickly<br />
  • 20. Spikes<br />http://github.com/BenHall/CastleDynamicProxy101/blob/master/CastleDynamicProxy101/Program.cs<br />http://github.com/BenHall/memcached101/blob/master/MemcacheDemo/Program.cs<br />
  • 21. NUnit makes learning repeatable<br />Helps guide the learning during implementation<br />
  • 22. Test Naming and structure<br />Pain killer<br />
  • 23. Each test should add something to explain the behaviour of the class under test<br />As you read down then it should continue to add more information in a logical way<br />Structure<br />
  • 24.
  • 25.
  • 26. Bad structure<br /> Method1_does_this<br /> Method2_does_this<br /> Method2_does_something_else<br /> Method1_does_not_do_this<br />EXAMPLE<br />
  • 27. Bad structure<br /> Method1_does_this<br /> Method1_does_not_do_this<br /> Method2_does_this<br /> Method2_does_something_else<br />EXAMPLE<br />
  • 28. Context Spec<br />Taken from Ruby<br />Example if the Persistent DLR integration<br />
  • 29. Naming of test <br />Implementation<br />I follow a BDD style which explains the behaviour<br />If your naming talks about implementation, then your likely to test implementation – this could change! <br />Like comments, you don’t want the test naming to be out of sync with what the actual test is doing<br />
  • 30. Actual test implementation<br />Painkiller<br />
  • 31. Make sure the important details are easy to identify<br />Hide the irrevent information to identify which bits are key<br />Variable names can help with this<br />varexpiredCreditCardDate = ...<br />Highlight relevant data<br />
  • 32. Duplicated Setup in test<br />Use Setup<br />Make test helpers which have pre-defined stub configs<br />EXAMPLE<br />
  • 33. Duplicated Setup in test<br />Use Setup<br />Make test helpers which have pre-defined stub configs<br />EXAMPLE<br />
  • 34.
  • 35. Tests are documentation<br />
  • 36. IT DEPENDS<br />
  • 37. Given, When, Then<br />
  • 38. Scenario: Payment method has expired<br /> Given user John<br /> And John has expired credit card<br /> When I get the default payment method<br /> Then an invalid credit card will be returned<br />Cuke4nuke SpecFlow<br />
  • 39.
  • 40. Design smells indicate it’s not done via TDD<br />
  • 41. Random, Dates, Machine Settings<br />DateTime.Now();<br />new Random().Next();<br />
  • 42. DateTimefunc<br />Random func<br />Use staticFunc<T> <br />
  • 43. EXTERNAL DEPENDENCIES<br />http://www.flickr.com/photos/gagilas/2659695352/<br />
  • 44. Fake the other side<br />
  • 45. Mock External Dependencies<br />
  • 46. Anti Corruption<br />http://www.flickr.com/photos/aresauburnphotos/2678453389/sizes/l/<br />
  • 47. Mock Usage<br />Not doing Unit Testing if you don’t use mocks<br />Over usage<br />ASP.net MVC is perfect example of having to do this<br />Stubs return stubs returning stubs<br />Too many mocks<br />Mocking things you don’t own<br />HttpContextBase<br />IDbConnection<br />
  • 48. http://ayende.com/Blog/archive/2006/07/02/DoNOTMockSystemData.aspx<br />
  • 49.
  • 50. Fragile to refactoring<br />Focusing too much on implementation<br />Needs to be behaviour driven<br />Incorrect Responsbilities<br />
  • 51. Running away from HttpContext<br />
  • 52. Interfaces establish behaviour boundaries. StubMock at boundaries<br />
  • 53. Let the tests drive the design<br />Scares some people. But again, it’s a learning tool so let it educate you!<br />
  • 54. http://www.flickr.com/photos/yakobusan/2436481628/<br />Application Design<br />
  • 55. Dependencies<br />IoC – Fear<br />TDD + IoC + Dependencies can lead to a very different application design<br />Fear is mainly because <br />
  • 56. Poor man’s IoC<br />
  • 57. REALLY?!?<br />
  • 58.
  • 59.
  • 60. Design Smell<br />Responsibilities of the class being tested<br />Fixture talks about lots of different concepts<br />Context Spec makes this a lot easier to identify<br />Easier to see if structured correctly<br />Smell - Responsibilities<br />http://www.flickr.com/photos/ricmcarthur/56268640/<br />
  • 61. Catalogue Handler<br />Tests help indicate smells<br />
  • 62. Catalogue Handler<br />Tests help indicate smells<br />Abstract away?<br />Combined service?<br />
  • 63.
  • 64. Single responsibility principle<br />Open/closed principle<br />Liskov substitution principle<br />Interface segregation principle<br />Dependency inversion principle<br />
  • 65. UI Testing<br />http://blig.ig.com.br/brokenarrow/files/2009/04/too_many_toolbars.jpg<br />
  • 66. WPF Apps With The Model-View-ViewModel Design Pattern<br />MVVM Pattern<br />http://msdn.microsoft.com/en-us/magazine/dd419663.aspx<br />
  • 67. MVP Pattern<br />
  • 68. MVP Pattern<br />
  • 69. Acceptance Test Driven Development<br />
  • 70. http://codebetter.com/blogs/benhall/archive/2010/03/16/testing-a-wpf-ui-using-ruby-cucumber-and-wipflash-dll.aspx<br />
  • 71. Scenario: Saving a product by name only      Given the application has started      And I enter the name "Product 1"      When I save the product      Then "Product 1" should be available to purchase <br />
  • 72.  Given /^the application has started$/ do    host = ApplicationLauncher.new    @app = host.launch Dir.pwd + '/src/ExampleUIs/bin/Debug/ExampleUIs.exe'    @main_window = @app.find_window 'petShopWindow'  end    Given /^I enter the name "([^"]*)"$/ do |product_name|    textbox = @main_window.find_TextBox "petNameInput"    textbox.text = product_name  end    When /^I save the product$/ do    button = @main_window.find_Button "petSaveButton"    button.click    sleep(1)  end    Then /^"([^"]*)" should be available to purchase$/ do |product_name|    combo = @main_window.find_ComboBox "basketInput"    combo.Items.should include("Pet[#{product_name}]")  end    After do |scenario|    @app.process.kill  end  <br />
  • 73. Full stack testing for ATDD?<br />Waste of time! <br />Feature coverage<br />Can be used as part of a test metric<br />
  • 74. What’s good application design?<br />When you read the code, it’s what you expect<br />How quickly you can add tests<br />How quickly you can implement new functionality<br />Understandable by the team<br />How much code churn ework is being performed<br />How much test coverage<br />
  • 75. Code Coverage<br />Waste of time! <br />Feature coverage<br />Can be used as part of a test metric<br />
  • 76. Code and Test Reviews<br />Better than metrics<br />What the team thinks is good<br />
  • 77. 7digital XTCR – Cross Team Code Review<br />At 7digital<br />
  • 78.
  • 79. It’s all about the mindset<br />
  • 80. Hardest part == getting started<br />
  • 81. Second hardest part == keep doing it<br />
  • 82. Becomes natural<br />
  • 83. Pair with someone<br />http://www.flickr.com/photos/jasohill/65804069/sizes/l/<br />
  • 84. Kata<br />http://www.flickr.com/photos/53511700@N06/4944542750/sizes/l/<br />
  • 85. Biggest Painkiller<br />Lizard Brain<br />Just do it!<br />Fear<br />http://www.flickr.com/photos/bartt/34937855/<br />
  • 86. End of the line<br />http://www.flickr.com/photos/leon_homan/2856628778/<br />
  • 87. Summary<br />Let the tests drive your design<br />Listen for smells<br />Fear – beat the lizard brain<br />just do it!<br />
  • 88. @Ben_Hall<br />Ben@BenHall.me.uk<br />Blog.BenHall.me.uk<br />http://www.flickr.com/photos/mike_c/4780493909/<br />

×