Tdd for BT E2E test community
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,154
On Slideshare
1,153
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
20
Comments
0
Likes
2

Embeds 1

http://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Transcript

  • 1. Test-drivendevelopment Kerry Buckley 26 July 2012
  • 2. Who the hell are you?
  • 3. What is TDD?
  • 4. Test-driven developmentFrom Wikipedia, the free encyclopediaTest-driven development (TDD) is a softwaredevelopment process that relies on the repetitionof a very short development cycle: first thedeveloper writes a failing automated test case thatdefines a desired improvement or new function,then produces code to pass that test and finallyrefactors the new code to acceptable standards.
  • 5. Terms
  • 6. Terms• Unit testing
  • 7. Terms• Unit testing• Integration testing
  • 8. Terms• Unit testing• Integration testing• Acceptance testing
  • 9. Towards TDD 0. manual testing WriteDesign Test Release code
  • 10. Towards TDD 1. automated testing Write WriteDesign Test Release code tests
  • 11. Towards TDD 2. test-first development Write WriteDesign Test Release tests code
  • 12. Towards TDD 3. test-driven developmentDesign Write Run Write test test code Release Run Refactor tests
  • 13. Towards TDD3. test-driven development Red Green Refactor
  • 14. Beyond TDD? 4. behaviour-driven development ExecutableCustomer Release examples Red Green TDD Refactor
  • 15. Unit test tools
  • 16. Unit test tools• Java: JUnit, TestNG…
  • 17. Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…
  • 18. Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…• Ruby: Test::Unit, MiniTest, RSpec…
  • 19. Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…• Ruby: Test::Unit, MiniTest, RSpec…• Javascript: JSUnit, JSSpec, Jasmine…
  • 20. Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…• Ruby: Test::Unit, MiniTest, RSpec…• Javascript: JSUnit, JSSpec, Jasmine…• and many more
  • 21. Acceptance test tools
  • 22. Acceptance test tools• Fit/Fitnesse
  • 23. Acceptance test tools• Fit/Fitnesse• Exactor
  • 24. Acceptance test tools• Fit/Fitnesse• Exactor• Selenium
  • 25. Acceptance test tools• Fit/Fitnesse• Exactor• Selenium• Cucumber
  • 26. Acceptance test tools• Fit/Fitnesse• Exactor• Selenium• Cucumber• Windmill
  • 27. Acceptance test tools• Fit/Fitnesse• Exactor• Selenium• Cucumber• Windmill• etc
  • 28. Anatomy of a test # Given some test accounts➊ Setup account_1 = Account.new(100) account_2 = Account.new(50) # When I transfer money➋ Act transfer(20, from: account_1, to: account_2) # Then the balances should be updated➌ Assert account_1.balance.should eq(80) account_2.balance.should eq(70)
  • 29. Acceptance tests Example using Cucumber
  • 30. Acceptance testsFeature: Logging in and out Scenario: User is greeted on login Given the user "Kerry" has an account When he logs in Then he should see "Welcome, Kerry"
  • 31. Acceptance tests$ cucumber login.featureFeature: Logging in and outScenario: User is greeted on loginGiven the user "Kerry" has an accountWhen he logs inThen he should see "Welcome, Kerry"1 scenario (1 undefined) 3 steps (3 undefined) 0m0.002s# login.feature:3 # login.feature:4 # login.feature:5 # login.feature:6You can implement step definitions for undefined steps withGiven /^the user "(.*?)" has an account$/ do |arg1| pending # express the regexp above with the code you wishend...
  • 32. Acceptance testsGiven /^the user "(.*?)" has an account$/ do |username| @user = User.create username: username, password: secretendWhen /^he logs in$/ do visit "/login" fill_in "User name", :with => @user.username fill_in "Password", :with => "secret" click_button "Log in"endThen /^he should see "(.*?)"$/ do |text| page.should have_text(text)end
  • 33. Acceptance tests$ cucumber login.featureFeature: Logging in and outScenario: User is greeted on loginGiven the user "Kerry" has an account # steps.rb:24When he logs in # steps.rb:28Then he should see "Welcome, Kerry" # steps.rb:35 expected there to be content "Log out" in "Welcome to the site!nTheresnothing here yet.” (RSpec::Expectations::ExpectationNotMetError) ./steps.rb:36:in `/^he should see "(.*?)"$/ login.feature:6:in `Then he should see "Welcome, Kerry"Failing Scenarios:cucumber login.feature:3 # Scenario: User is greeted on login1 scenario (1 failed)3 steps (1 failed, 2 passed) 0m0.002s
  • 34. Acceptance tests$ cucumber login.featureFeature: Logging in and outScenario: User is greeted on loginGiven the user "Kerry" has an account # steps.rb:24When he logs in # steps.rb:28Then he should see "Welcome, Kerry" # steps.rb:351 scenario (1 passed) 3 steps (3 passed) 0m0.003s
  • 35. Unit testsExample using RSpec
  • 36. Unit testsdescribe Calculator do it "can add two numbers" do calculator = Calculator.new calculator.add(2, 3).should eq(" 5") endend
  • 37. Unit tests$ rspec calculator_spec.rbcalculator_spec.rb:1:in `<top (required)>:uninitialized constant Calculator (NameError)
  • 38. Unit testsclass Calculatorend
  • 39. Unit tests$ rspec calculator_spec.rbFFailures:1) Calculator can add two numbersFailure/Error: calculator.add(2, 3).should eq(5) NoMethodError: undefined method `add for #<Calculator:0x007fa0ac1ea718># ./calculator_spec.rb:6:in `block (2 levels) in <top (required)>Finished in 0.00035 seconds1 example, 1 failureFailed examples:rspec ./calculator_spec.rb:4 # Calculator can add two numbers
  • 40. Unit testsclass Calculator def add endend
  • 41. Unit tests$ rspec calculator_spec.rbFFailures: 1) Calculator can add two numbers Failure/Error: calculator.add(2, 3).should eq(" 5") ArgumentError: wrong number of arguments (2 for 0) #  ./calculator.rb:2:in `add #  ./calculator_spec.rb:6:in `block (2 levels) in <top (required)>Finished in 0.0005 seconds1 example, 1 failureFailed examples:rspec ./calculator_spec.rb:4 # Calculator can add two numbers
  • 42. Unit testsclass Calculator def add a, b endend
  • 43. Unit tests$ rspec calculator_spec.rbFFailures: 1) Calculator can add two numbers Failure/Error: calculator.add(2, 3).should eq(" 5") expected: " 5" got: nil (compared using ==) # ./calculator_spec.rb:6:in `block (2 levels) in <top (required)>Finished in 0.00066 seconds1 example, 1 failureFailed examples:rspec ./calculator_spec.rb:4 # Calculator can add two numbers
  • 44. Unit testsclass Calculator def add a, b " #{a + b}" endend
  • 45. Unit tests$ rspec calculator_spec.rb.Finished in 0.00065 seconds1 example, 0 failures
  • 46. Unit testsdescribe Calculator do it "can add two numbers" do calculator = Calculator.new calculator.add(2, 3).should eq(" 5") end it "pads output to eight characters" do calculator = Calculator.new calculator.add(2, 2).should eq(" 4") calculator.add(5, 5).should eq(" 10") endend
  • 47. Unit tests$ rspec calculator_spec.rb.FFailures: 1) Calculator pads output to eight characters Failure/Error: calculator.add(5, 5).should eq(" 10") expected: " 10" got: " 10" (compared using ==) # ./calculator_spec.rb:12:in `block (2 levels) in <top (required)>Finished in 0.00086 seconds2 examples, 1 failureFailed examples:rspec ./calculator_spec.rb:9 # Calculator pads output to eight characters
  • 48. Unit testsclass Calculator def add a, b "%8i" % (a + b) endend
  • 49. Unit tests$ rspec calculator_spec.rb..Finished in 0.00076 seconds2 examples, 0 failures
  • 50. Unit testsdescribe Calculator do it "can add two numbers" do calculator = Calculator.new calculator.add(2, 3).should eq(" 5") end it "pads output to eight characters" do calculator = Calculator.new calculator.add(2, 2).should eq(" 4") calculator.add(5, 5).should eq(" 10") endend
  • 51. Unit testsdescribe Calculator do before do @calculator = Calculator.new end it "can add two numbers" do @calculator.add(2, 3).should eq(" 5") end it "pads output to eight characters" do @calculator.add(2, 2).should eq(" 4") @calculator.add(5, 5).should eq(" 10") endend
  • 52. Unit tests$ rspec calculator_spec.rb..Finished in 0.00075 seconds2 examples, 0 failures
  • 53. Unit testsdescribe Calculator do before do @calculator = Calculator.new end it "can add two numbers" do @calculator.add(2, 3).should eq(" 5") end it "can subtract two numbers" do @calculator.subtract(3, 1).should eq(" 2") end it "pads output to eight characters" do @calculator.add(2, 2).should eq(" 4") @calculator.add(5, 5).should eq(" 10") endend
  • 54. Unit testsclass Calculator def add a, b "%8i" % (a + b) end def subtract a, b "%8i" % (a - b) endend
  • 55. Unit tests$ rspec calculator_spec.rb...Finished in 0.00085 seconds3 examples, 0 failures
  • 56. Unit testsclass Calculator def add a, b "%8i" % (a + b) end def subtract a, b "%8i" % (a - b) endend
  • 57. Unit testsclass Calculator def add a, b format(a + b) end def subtract a, b format(a - b) end private def format number "%8i" % number endend
  • 58. Unit tests$ rspec calculator_spec.rb...Finished in 0.00086 seconds3 examples, 0 failures
  • 59. Unit testsdescribe Calculator do before do @calculator = Calculator.new end it "can add two numbers" do @calculator.add(2, 3).should eq(" 5") end it "pads output to eight characters" do @calculator.add(2, 2).should eq(" 4") @calculator.add(5, 5).should eq(" 10") endend
  • 60. Unit tests$ rspec --format doc calculator_spec.rbCalculator can add two numbers can subtract two numbers pads output to eight charactersFinished in 0.00094 seconds3 examples, 0 failures
  • 61. A good test suite…
  • 62. A good test suite…• Expresses the programmer’s intent
  • 63. A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works
  • 64. A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works• Runs quickly
  • 65. A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works• Runs quickly• Gives clear failure messages
  • 66. A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works• Runs quickly• Gives clear failure messages• Is well-maintained
  • 67. A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works• Runs quickly• Gives clear failure messages• Is well-maintained• Isolates each area under test
  • 68. Benefits of TDD
  • 69. Benefits of TDD• Less manual testing required
  • 70. Benefits of TDD• Less manual testing required• Faster feedback
  • 71. Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer
  • 72. Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer• Shorter cycle time
  • 73. Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer• Shorter cycle time• Reduced rework
  • 74. Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer• Shorter cycle time• Reduced rework• Improved design
  • 75. What about testers?
  • 76. What about testers?• Less tedious repetitive manual testing
  • 77. What about testers?• Less tedious repetitive manual testing• Concentrate on exploratory testing
  • 78. What about testers?• Less tedious repetitive manual testing• Concentrate on exploratory testing• Identify edge cases and ‘sad path’ tests
  • 79. What about testers?• Less tedious repetitive manual testing• Concentrate on exploratory testing• Identify edge cases and ‘sad path’ tests• Help define acceptance tests
  • 80. How do I start?
  • 81. How do I start?• Greenfield project? JFDI! Otherwise…
  • 82. How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first
  • 83. How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first • Important features
  • 84. How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first • Important features • Where the most bugs occur
  • 85. How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first • Important features • Where the most bugs occur• Use TDD for new features
  • 86. How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first • Important features • Where the most bugs occur• Use TDD for new features• Add tests for bugs when they’re found
  • 87. Further reading
  • 88. Discussion