Tdd for BT E2E test community

  • 730 views
Uploaded on

 

More in: Technology
  • 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
730
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
20
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