Downloaded 26 times
![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](https://image.slidesharecdn.com/tddpainkillersdddiepublic-101009061359-phpapp02/85/TDD-Painkillers-72-320.jpg)
Uploaded byBen Hall
TDD Painkillers
The document discusses the challenges and best practices of Test-Driven Development (TDD), emphasizing the importance of proper test design, behavior-driven development, and minimizing irrelevant information. It highlights the role of test naming, use of mocks, and the significance of focusing on behavior rather than implementation details. Additionally, it mentions acceptance test-driven development principles and encourages developers to embrace TDD as a learning tool while addressing common fears associated with it.
More Related Content
TDD Painkillers
- 1.
- 2. London based ASP.netMVPWeb Developer @ 7digital.com Open Source DeveloperWHO AM I?Co-Author Testing ASP.net Web Applicationswww.testingaspnet.com
- 3.
- 4.
- 5.
- 6. TDD doesn’t meanNUnit
- 7. TDD is aboutlearning
- 8. TDD is aboutvalidating the unknownsProving your own assumptions
- 9. Fundamentally the biggestTDD painkiller is not doing TDD
- 10. That’s why wehave a QA department
- 11. Ideally PairingDeveloper writingthe testDeveloper writing the implementation
- 12. Do enough justto get the test to pass
- 13. Write more teststo express more behaviour
- 14. Wouldn’t it becool if...
- 15.
- 16. Takes longer toachieve what you wanted to deliverDo the simplest thing possible.“First make it work, then make it right”
- 17. “TDD like youmeant it”
- 18.
- 19. IRB (Ruby)Want rapidfeedbackAllows you to learn quickly
- 20.
- 21. NUnit makes learningrepeatableHelps guide the learning during implementation
- 22. Test Naming andstructurePain killer
- 23. Each test shouldadd something to explain the behaviour of the class under testAs you read down then it should continue to add more information in a logical wayStructure
- 26. Bad structure Method1_does_this Method2_does_this Method2_does_something_else Method1_does_not_do_thisEXAMPLE
- 27. Bad structure Method1_does_this Method1_does_not_do_this Method2_does_this Method2_does_something_elseEXAMPLE
- 28. Context \ SpecTakenfrom RubyExample if the Persistent DLR integration
- 29. Naming of testImplementationI follow a BDD style which explains the behaviourIf 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.
- 31. Make sure theimportant details are easy to identifyHide the irrevent information to identify which bits are keyVariable names can help with thisvarexpiredCreditCardDate = ...Highlight relevant data
- 32. Duplicated Setup intestUse SetupMake test helpers which have pre-defined stub configsEXAMPLE
- 33. Duplicated Setup intestUse SetupMake test helpers which have pre-defined stub configsEXAMPLE
- 35.
- 36.
- 37.
- 38. Scenario: Payment methodhas expired Given user John And John has expired credit card When I get the default payment method Then an invalid credit card will be returnedCuke4nuke \ SpecFlow
- 40. Design smells indicateit’s not done via TDD
- 41. Random, Dates, MachineSettingsDateTime.Now();new Random().Next();
- 42.
- 43.
- 44. Fake the otherside
- 45.
- 46.
- 47. Mock UsageNot doingUnit Testing if you don’t use mocksOver usageASP.net MVC is perfect example of having to do thisStubs return stubs returning stubsToo many mocksMocking things you don’t ownHttpContextBaseIDbConnection
- 48.
- 50. Fragile to refactoringFocusingtoo much on implementationNeeds to be behaviour drivenIncorrect Responsbilities
- 51. Running away fromHttpContext
- 52. Interfaces establish behaviourboundaries. Stub\Mock at boundaries
- 53. Let the testsdrive the designScares some people. But again, it’s a learning tool so let it educate you!
- 54.
- 55. DependenciesIoC – FearTDD+ IoC + Dependencies can lead to a very different application designFear is mainly because
- 56.
- 57.
- 60. Design SmellResponsibilities ofthe class being testedFixture talks about lots of different conceptsContext \ Spec makes this a lot easier to identifyEasier to see if structured correctlySmell - Responsibilitieshttp://www.flickr.com/photos/ricmcarthur/56268640/
- 61. Catalogue HandlerTests helpindicate smells
- 62. Catalogue HandlerTests helpindicate smellsAbstract away?Combined service?
- 64. Single responsibility principleOpen/closedprincipleLiskov substitution principleInterface segregation principleDependency inversion principle
- 65.
- 66. WPF Apps WithThe Model-View-ViewModel Design PatternMVVM Patternhttp://msdn.microsoft.com/en-us/magazine/dd419663.aspx
- 67.
- 68.
- 69. Acceptance Test DrivenDevelopment
- 70.
- 71. Scenario: Saving aproduct 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 applicationhas 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
- 73. Full stack testingfor ATDD?Waste of time! Feature coverageCan be used as part of a test metric
- 74. What’s good applicationdesign?When you read the code, it’s what you expectHow quickly you can add testsHow quickly you can implement new functionalityUnderstandable by the teamHow much code churn\rework is being performedHow much test coverage
- 75. Code CoverageWaste oftime! Feature coverageCan be used as part of a test metric
- 76. Code and TestReviewsBetter than metricsWhat the team thinks is good
- 77. 7digital XTCR –Cross Team Code ReviewAt 7digital
- 79. It’s all aboutthe mindset
- 80. Hardest part ==getting started
- 81. Second hardest part== keep doing it
- 82.
- 83.
- 84.