0
C# TDD Painkillers<br />@Ben_Hall<br />Ben@BenHall.me.uk<br />Blog.BenHall.me.uk<br />CodeBetter.com/blogs/BenHall<br />ht...
London based ASP.net MVPWeb Developer @ 7digital.com <br />Open Source Developer<br />WHO AM I?<br />Co-Author <br />Testi...
You<br />Test Design<br />App Design<br />
http://www.flickr.com/photos/chiotsrun/4115059294/sizes/l/<br />
Test Design<br />http://www.flickr.com/photos/nyuhuhuu/4442144329/<br />
TDD doesn’t mean NUnit<br />
TDD is about learning<br />
TDD is about validating the unknowns<br />Proving your own assumptions<br />
Fundamentally the biggest TDD painkiller is not doing TDD<br />
That’s why we have a QA department<br />
Ideally Pairing<br />Developer writing the testDeveloper writing the implementation<br />
<ul><li>Do enough just to get the test to pass
Write more tests to express more behaviour
Wouldn’t it be cool if...
Loose focus
Takes longer to achieve what you wanted to deliver</li></ul>Do the simplest thing possible.“First make it work, then make ...
“TDD like you meant it”<br />
http://www.flickr.com/photos/peasap/1625639532/sizes/l/<br />Spike<br />
IRB (Ruby)<br />Want rapid feedback<br />Allows you to learn quickly<br />
Spikes<br />http://github.com/BenHall/CastleDynamicProxy101/blob/master/CastleDynamicProxy101/Program.cs<br />http://githu...
NUnit makes learning repeatable<br />Helps guide the learning during implementation<br />
Test Naming and structure<br />Pain killer<br />
Each test should add something to explain the behaviour of the class under test<br />As you read down then it should conti...
Bad structure<br />    Method1_does_this<br />    Method2_does_this<br />    Method2_does_something_else<br />    Method1_...
Bad structure<br />    Method1_does_this<br />    Method1_does_not_do_this<br />    Method2_does_this<br />    Method2_doe...
Context  Spec<br />Taken from Ruby<br />Example if the Persistent DLR integration<br />
Naming of test <br />Implementation<br />I follow a BDD style which explains the behaviour<br />If your naming talks about...
Actual test implementation<br />Painkiller<br />
Make sure the important details are easy to identify<br />Hide the irrevent information to identify which bits are key<br ...
Duplicated Setup in test<br />Use Setup<br />Make test helpers which have pre-defined stub configs<br />EXAMPLE<br />
Duplicated Setup in test<br />Use Setup<br />Make test helpers which have pre-defined stub configs<br />EXAMPLE<br />
Tests are documentation<br />
IT DEPENDS<br />
Given, When, Then<br />
Scenario: Payment method has expired<br />   Given user John<br />   And John has expired credit card<br />   When I get t...
Design smells indicate it’s not done via TDD<br />
Random, Dates, Machine Settings<br />DateTime.Now();<br />new Random().Next();<br />
DateTimefunc<br />Random func<br />Use staticFunc<T>    <br />
EXTERNAL DEPENDENCIES<br />http://www.flickr.com/photos/gagilas/2659695352/<br />
Fake the other side<br />
Mock External Dependencies<br />
Anti Corruption<br />http://www.flickr.com/photos/aresauburnphotos/2678453389/sizes/l/<br />
Mock Usage<br />Not doing Unit Testing if you don’t use mocks<br />Over usage<br />ASP.net MVC is perfect example of havin...
http://ayende.com/Blog/archive/2006/07/02/DoNOTMockSystemData.aspx<br />
Fragile to refactoring<br />Focusing too much on implementation<br />Needs to be behaviour driven<br />Incorrect Responsbi...
Running away from HttpContext<br />
Interfaces establish behaviour boundaries. StubMock at boundaries<br />
Let the tests drive the design<br />Scares some people. But again, it’s a learning tool so let it educate you!<br />
http://www.flickr.com/photos/yakobusan/2436481628/<br />Application Design<br />
Dependencies<br />IoC – Fear<br />TDD + IoC + Dependencies can lead to a very different application design<br />Fear is ma...
Poor man’s IoC<br />
REALLY?!?<br />
Design Smell<br />Responsibilities of the class being tested<br />Fixture talks about lots of different concepts<br />Cont...
Catalogue Handler<br />Tests help indicate smells<br />
Catalogue Handler<br />Tests help indicate smells<br />Abstract away?<br />Combined service?<br />
Single responsibility principle<br />Open/closed principle<br />Liskov substitution principle<br />Interface segregation p...
UI Testing<br />http://blig.ig.com.br/brokenarrow/files/2009/04/too_many_toolbars.jpg<br />
WPF Apps With The Model-View-ViewModel Design Pattern<br />MVVM Pattern<br />http://msdn.microsoft.com/en-us/magazine/dd41...
MVP Pattern<br />
MVP Pattern<br />
Acceptance Test Driven Development<br />
http://codebetter.com/blogs/benhall/archive/2010/03/16/testing-a-wpf-ui-using-ruby-cucumber-and-wipflash-dll.aspx<br />
Scenario: Saving a product by name only      Given the application has started      And I enter the name "Product 1"      ...
 Given /^the application has started$/ do    host = ApplicationLauncher.new    @app = host.launch Dir.pwd + '/src/ExampleU...
Full stack testing for ATDD?<br />Waste of time! <br />Feature coverage<br />Can be used as part of a test metric<br />
What’s good application design?<br />When you read the code, it’s what you expect<br />How quickly you can add tests<br />...
Code Coverage<br />Waste of time! <br />Feature coverage<br />Can be used as part of a test metric<br />
Code and Test Reviews<br />Better than metrics<br />What the team thinks is good<br />
7digital XTCR – Cross Team Code Review<br />At 7digital<br />
It’s all about the mindset<br />
Hardest part == getting started<br />
Second hardest part == keep doing it<br />
Becomes natural<br />
Pair with someone<br />http://www.flickr.com/photos/jasohill/65804069/sizes/l/<br />
Kata<br />http://www.flickr.com/photos/53511700@N06/4944542750/sizes/l/<br />
Upcoming SlideShare
Loading in...5
×

TDD Painkillers

4,084

Published on

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,084
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "TDD Painkillers"

  1. 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. 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. 3. You<br />Test Design<br />App Design<br />
  4. 4. http://www.flickr.com/photos/chiotsrun/4115059294/sizes/l/<br />
  5. 5. Test Design<br />http://www.flickr.com/photos/nyuhuhuu/4442144329/<br />
  6. 6. TDD doesn’t mean NUnit<br />
  7. 7. TDD is about learning<br />
  8. 8. TDD is about validating the unknowns<br />Proving your own assumptions<br />
  9. 9. Fundamentally the biggest TDD painkiller is not doing TDD<br />
  10. 10. That’s why we have a QA department<br />
  11. 11. Ideally Pairing<br />Developer writing the testDeveloper writing the implementation<br />
  12. 12. <ul><li>Do enough just to get the test to pass
  13. 13. Write more tests to express more behaviour
  14. 14. Wouldn’t it be cool if...
  15. 15. Loose focus
  16. 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. 17. “TDD like you meant it”<br />
  18. 18. http://www.flickr.com/photos/peasap/1625639532/sizes/l/<br />Spike<br />
  19. 19. IRB (Ruby)<br />Want rapid feedback<br />Allows you to learn quickly<br />
  20. 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. 21. NUnit makes learning repeatable<br />Helps guide the learning during implementation<br />
  22. 22. Test Naming and structure<br />Pain killer<br />
  23. 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. 24.
  25. 25.
  26. 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. 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. 28. Context Spec<br />Taken from Ruby<br />Example if the Persistent DLR integration<br />
  29. 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. 30. Actual test implementation<br />Painkiller<br />
  31. 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. 32. Duplicated Setup in test<br />Use Setup<br />Make test helpers which have pre-defined stub configs<br />EXAMPLE<br />
  33. 33. Duplicated Setup in test<br />Use Setup<br />Make test helpers which have pre-defined stub configs<br />EXAMPLE<br />
  34. 34.
  35. 35. Tests are documentation<br />
  36. 36. IT DEPENDS<br />
  37. 37. Given, When, Then<br />
  38. 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. 39.
  40. 40. Design smells indicate it’s not done via TDD<br />
  41. 41. Random, Dates, Machine Settings<br />DateTime.Now();<br />new Random().Next();<br />
  42. 42. DateTimefunc<br />Random func<br />Use staticFunc<T> <br />
  43. 43. EXTERNAL DEPENDENCIES<br />http://www.flickr.com/photos/gagilas/2659695352/<br />
  44. 44. Fake the other side<br />
  45. 45. Mock External Dependencies<br />
  46. 46. Anti Corruption<br />http://www.flickr.com/photos/aresauburnphotos/2678453389/sizes/l/<br />
  47. 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. 48. http://ayende.com/Blog/archive/2006/07/02/DoNOTMockSystemData.aspx<br />
  49. 49.
  50. 50. Fragile to refactoring<br />Focusing too much on implementation<br />Needs to be behaviour driven<br />Incorrect Responsbilities<br />
  51. 51. Running away from HttpContext<br />
  52. 52. Interfaces establish behaviour boundaries. StubMock at boundaries<br />
  53. 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. 54. http://www.flickr.com/photos/yakobusan/2436481628/<br />Application Design<br />
  55. 55. Dependencies<br />IoC – Fear<br />TDD + IoC + Dependencies can lead to a very different application design<br />Fear is mainly because <br />
  56. 56. Poor man’s IoC<br />
  57. 57. REALLY?!?<br />
  58. 58.
  59. 59.
  60. 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. 61. Catalogue Handler<br />Tests help indicate smells<br />
  62. 62. Catalogue Handler<br />Tests help indicate smells<br />Abstract away?<br />Combined service?<br />
  63. 63.
  64. 64. Single responsibility principle<br />Open/closed principle<br />Liskov substitution principle<br />Interface segregation principle<br />Dependency inversion principle<br />
  65. 65. UI Testing<br />http://blig.ig.com.br/brokenarrow/files/2009/04/too_many_toolbars.jpg<br />
  66. 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. 67. MVP Pattern<br />
  68. 68. MVP Pattern<br />
  69. 69. Acceptance Test Driven Development<br />
  70. 70. http://codebetter.com/blogs/benhall/archive/2010/03/16/testing-a-wpf-ui-using-ruby-cucumber-and-wipflash-dll.aspx<br />
  71. 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. 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. 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. 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. 75. Code Coverage<br />Waste of time! <br />Feature coverage<br />Can be used as part of a test metric<br />
  76. 76. Code and Test Reviews<br />Better than metrics<br />What the team thinks is good<br />
  77. 77. 7digital XTCR – Cross Team Code Review<br />At 7digital<br />
  78. 78.
  79. 79. It’s all about the mindset<br />
  80. 80. Hardest part == getting started<br />
  81. 81. Second hardest part == keep doing it<br />
  82. 82. Becomes natural<br />
  83. 83. Pair with someone<br />http://www.flickr.com/photos/jasohill/65804069/sizes/l/<br />
  84. 84. Kata<br />http://www.flickr.com/photos/53511700@N06/4944542750/sizes/l/<br />
  85. 85. Biggest Painkiller<br />Lizard Brain<br />Just do it!<br />Fear<br />http://www.flickr.com/photos/bartt/34937855/<br />
  86. 86. End of the line<br />http://www.flickr.com/photos/leon_homan/2856628778/<br />
  87. 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. 88. @Ben_Hall<br />Ben@BenHall.me.uk<br />Blog.BenHall.me.uk<br />http://www.flickr.com/photos/mike_c/4780493909/<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×