TDD Painkillers
Upcoming SlideShare
Loading in...5
×
 

TDD Painkillers

on

  • 4,461 views

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.

Statistics

Views

Total Views
4,461
Views on SlideShare
2,481
Embed Views
1,980

Actions

Likes
1
Downloads
18
Comments
0

10 Embeds 1,980

http://blog.benhall.me.uk 1834
http://localhost 84
http://feeds.feedburner.com 39
http://localhost:3004 10
http://mrk-et.herokuapp.com 3
http://static.slidesharecdn.com 3
http://mayday-et.herokuapp.com 3
http://md-et.herokuapp.com 2
http://webcache.googleusercontent.com 1
http://translate.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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.

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

TDD Painkillers TDD Painkillers Presentation Transcript

  • C# TDD Painkillers
    @Ben_Hall
    Ben@BenHall.me.uk
    Blog.BenHall.me.uk
    CodeBetter.com/blogs/BenHall
    http://www.flickr.com/photos/pinksherbet/4004791663/
  • London based ASP.net MVPWeb Developer @ 7digital.com
    Open Source Developer
    WHO AM I?
    Co-Author
    Testing ASP.net Web Applications
    www.testingaspnet.com
  • You
    Test Design
    App Design
  • http://www.flickr.com/photos/chiotsrun/4115059294/sizes/l/
  • Test Design
    http://www.flickr.com/photos/nyuhuhuu/4442144329/
  • TDD doesn’t mean NUnit
  • TDD is about learning
  • TDD is about validating the unknowns
    Proving your own assumptions
  • Fundamentally the biggest TDD painkiller is not doing TDD
  • That’s why we have a QA department
  • Ideally Pairing
    Developer writing the testDeveloper writing the implementation
    • 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
    Do the simplest thing possible.“First make it work, then make it right”
  • “TDD like you meant it”
  • http://www.flickr.com/photos/peasap/1625639532/sizes/l/
    Spike
  • IRB (Ruby)
    Want rapid feedback
    Allows you to learn quickly
  • Spikes
    http://github.com/BenHall/CastleDynamicProxy101/blob/master/CastleDynamicProxy101/Program.cs
    http://github.com/BenHall/memcached101/blob/master/MemcacheDemo/Program.cs
  • NUnit makes learning repeatable
    Helps guide the learning during implementation
  • Test Naming and structure
    Pain killer
  • 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
    Structure
  • Bad structure
    Method1_does_this
    Method2_does_this
    Method2_does_something_else
    Method1_does_not_do_this
    EXAMPLE
  • Bad structure
    Method1_does_this
    Method1_does_not_do_this
    Method2_does_this
    Method2_does_something_else
    EXAMPLE
  • Context Spec
    Taken from Ruby
    Example if the Persistent DLR integration
  • Naming of test
    Implementation
    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
  • Actual test implementation
    Painkiller
  • 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
  • Duplicated Setup in test
    Use Setup
    Make test helpers which have pre-defined stub configs
    EXAMPLE
  • Duplicated Setup in test
    Use Setup
    Make test helpers which have pre-defined stub configs
    EXAMPLE
  • Tests are documentation
  • IT DEPENDS
  • Given, When, Then
  • 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
  • Design smells indicate it’s not done via TDD
  • Random, Dates, Machine Settings
    DateTime.Now();
    new Random().Next();
  • DateTimefunc
    Random func
    Use staticFunc<T>
  • EXTERNAL DEPENDENCIES
    http://www.flickr.com/photos/gagilas/2659695352/
  • Fake the other side
  • Mock External Dependencies
  • Anti Corruption
    http://www.flickr.com/photos/aresauburnphotos/2678453389/sizes/l/
  • Mock Usage
    Not doing Unit Testing if you don’t use mocks
    Over usage
    ASP.net MVC is perfect example of having to do this
    Stubs return stubs returning stubs
    Too many mocks
    Mocking things you don’t own
    HttpContextBase
    IDbConnection
  • http://ayende.com/Blog/archive/2006/07/02/DoNOTMockSystemData.aspx
  • Fragile to refactoring
    Focusing too much on implementation
    Needs to be behaviour driven
    Incorrect Responsbilities
  • Running away from HttpContext
  • Interfaces establish behaviour boundaries. StubMock at boundaries
  • Let the tests drive the design
    Scares some people. But again, it’s a learning tool so let it educate you!
  • http://www.flickr.com/photos/yakobusan/2436481628/
    Application Design
  • Dependencies
    IoC – Fear
    TDD + IoC + Dependencies can lead to a very different application design
    Fear is mainly because
  • Poor man’s IoC
  • REALLY?!?
  • 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
    http://www.flickr.com/photos/ricmcarthur/56268640/
  • Catalogue Handler
    Tests help indicate smells
  • Catalogue Handler
    Tests help indicate smells
    Abstract away?
    Combined service?
  • Single responsibility principle
    Open/closed principle
    Liskov substitution principle
    Interface segregation principle
    Dependency inversion principle
  • UI Testing
    http://blig.ig.com.br/brokenarrow/files/2009/04/too_many_toolbars.jpg
  • WPF Apps With The Model-View-ViewModel Design Pattern
    MVVM Pattern
    http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
  • MVP Pattern
  • MVP Pattern
  • Acceptance Test Driven Development
  • http://codebetter.com/blogs/benhall/archive/2010/03/16/testing-a-wpf-ui-using-ruby-cucumber-and-wipflash-dll.aspx
  • 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 
  •  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  
  • Full stack testing for ATDD?
    Waste of time!
    Feature coverage
    Can be used as part of a test metric
  • 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
  • Code Coverage
    Waste of time!
    Feature coverage
    Can be used as part of a test metric
  • Code and Test Reviews
    Better than metrics
    What the team thinks is good
  • 7digital XTCR – Cross Team Code Review
    At 7digital
  • It’s all about the mindset
  • Hardest part == getting started
  • Second hardest part == keep doing it
  • Becomes natural
  • Pair with someone
    http://www.flickr.com/photos/jasohill/65804069/sizes/l/
  • Kata
    http://www.flickr.com/photos/53511700@N06/4944542750/sizes/l/
  • Biggest Painkiller
    Lizard Brain
    Just do it!
    Fear
    http://www.flickr.com/photos/bartt/34937855/
  • End of the line
    http://www.flickr.com/photos/leon_homan/2856628778/
  • Summary
    Let the tests drive your design
    Listen for smells
    Fear – beat the lizard brain
    just do it!
  • @Ben_Hall
    Ben@BenHall.me.uk
    Blog.BenHall.me.uk
    http://www.flickr.com/photos/mike_c/4780493909/