• Like
  • Save
TDD Painkillers
Upcoming SlideShare
Loading in...5
×
 

TDD Painkillers

on

  • 4,444 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,444
Views on SlideShare
2,464
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/