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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Tdd for BT E2E test community

761
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
761
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
0
Likes
2
Embeds 0
No embeds

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