Your SlideShare is downloading. ×
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


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.

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. C# TDD Painkillers
  • 2. London based MVPWeb Developer @
    Open Source Developer
    WHO AM I?
    Testing Web Applications
  • 3. You
    Test Design
    App Design
  • 4.
  • 5. Test Design
  • 6. TDD doesn’t mean NUnit
  • 7. TDD is about learning
  • 8. TDD is about validating the unknowns
    Proving your own assumptions
  • 9. Fundamentally the biggest TDD painkiller is not doing TDD
  • 10. That’s why we have a QA department
  • 11. Ideally Pairing
    Developer writing the testDeveloper writing the implementation
  • 12.
    • 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
    Do the simplest thing possible.“First make it work, then make it right”
  • 17. “TDD like you meant it”
  • 18.
  • 19. IRB (Ruby)
    Want rapid feedback
    Allows you to learn quickly
  • 20. Spikes
  • 21. NUnit makes learning repeatable
    Helps guide the learning during implementation
  • 22. Test Naming and structure
    Pain killer
  • 23. Each test should add something to explain the behaviour of the class under test
    As you read down then it should continue to add more information in a logical way
  • 24.
  • 25.
  • 26. Bad structure
  • 27. Bad structure
  • 28. Context Spec
    Taken from Ruby
    Example if the Persistent DLR integration
  • 29. Naming of test
    I follow a BDD style which explains the behaviour
    If your naming talks about implementation, then your likely to test implementation – this could change!
    Like comments, you don’t want the test naming to be out of sync with what the actual test is doing
  • 30. Actual test implementation
  • 31. Make sure the important details are easy to identify
    Hide the irrevent information to identify which bits are key
    Variable names can help with this
    varexpiredCreditCardDate = ...
    Highlight relevant data
  • 32. Duplicated Setup in test
    Use Setup
    Make test helpers which have pre-defined stub configs
  • 33. Duplicated Setup in test
    Use Setup
    Make test helpers which have pre-defined stub configs
  • 34.
  • 35. Tests are documentation
  • 36. IT DEPENDS
  • 37. Given, When, Then
  • 38. Scenario: Payment method has expired
    Given user John
    And John has expired credit card
    When I get the default payment method
    Then an invalid credit card will be returned
    Cuke4nuke SpecFlow
  • 39.
  • 40. Design smells indicate it’s not done via TDD
  • 41. Random, Dates, Machine Settings
    new Random().Next();
  • 42. DateTimefunc
    Random func
    Use staticFunc<T>
  • 44. Fake the other side
  • 45. Mock External Dependencies
  • 46. Anti Corruption
  • 47. Mock Usage
    Not doing Unit Testing if you don’t use mocks
    Over usage MVC is perfect example of having to do this
    Stubs return stubs returning stubs
    Too many mocks
    Mocking things you don’t own
  • 48.
  • 49.
  • 50. Fragile to refactoring
    Focusing too much on implementation
    Needs to be behaviour driven
    Incorrect Responsbilities
  • 51. Running away from HttpContext
  • 52. Interfaces establish behaviour boundaries. StubMock at boundaries
  • 53. Let the tests drive the design
    Scares some people. But again, it’s a learning tool so let it educate you!
  • 54.
    Application Design
  • 55. Dependencies
    IoC – Fear
    TDD + IoC + Dependencies can lead to a very different application design
    Fear is mainly because
  • 56. Poor man’s IoC
  • 57. REALLY?!?
  • 58.
  • 59.
  • 60. Design Smell
    Responsibilities of the class being tested
    Fixture talks about lots of different concepts
    Context Spec makes this a lot easier to identify
    Easier to see if structured correctly
    Smell - Responsibilities
  • 61. Catalogue Handler
    Tests help indicate smells
  • 62. Catalogue Handler
    Tests help indicate smells
    Abstract away?
    Combined service?
  • 63.
  • 64. Single responsibility principle
    Open/closed principle
    Liskov substitution principle
    Interface segregation principle
    Dependency inversion principle
  • 65. UI Testing
  • 66. WPF Apps With The Model-View-ViewModel Design Pattern
    MVVM Pattern
  • 67. MVP Pattern
  • 68. MVP Pattern
  • 69. Acceptance Test Driven Development
  • 70.
  • 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 
  • 72.  Given /^the application has started$/ do    host =    @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"    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  
  • 73. Full stack testing for ATDD?
    Waste of time!
    Feature coverage
    Can be used as part of a test metric
  • 74. What’s good application design?
    When you read the code, it’s what you expect
    How quickly you can add tests
    How quickly you can implement new functionality
    Understandable by the team
    How much code churn ework is being performed
    How much test coverage
  • 75. Code Coverage
    Waste of time!
    Feature coverage
    Can be used as part of a test metric
  • 76. Code and Test Reviews
    Better than metrics
    What the team thinks is good
  • 77. 7digital XTCR – Cross Team Code Review
    At 7digital
  • 78.
  • 79. It’s all about the mindset
  • 80. Hardest part == getting started
  • 81. Second hardest part == keep doing it
  • 82. Becomes natural
  • 83. Pair with someone
  • 84. Kata
  • 85. Biggest Painkiller
    Lizard Brain
    Just do it!
  • 86. End of the line
  • 87. Summary
    Let the tests drive your design
    Listen for smells
    Fear – beat the lizard brain
    just do it!
  • 88. @Ben_Hall