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

Tdd for BT E2E test community

on

  • 1,060 views

 

Statistics

Views

Total Views
1,060
Views on SlideShare
1,059
Embed Views
1

Actions

Likes
2
Downloads
20
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

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
  • \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

Tdd for BT E2E test community Tdd for BT E2E test community Presentation Transcript

  • Test-drivendevelopment Kerry Buckley 26 July 2012
  • Who the hell are you?
  • What is TDD?
  • 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.
  • Terms
  • Terms• Unit testing
  • Terms• Unit testing• Integration testing
  • Terms• Unit testing• Integration testing• Acceptance testing
  • Towards TDD 0. manual testing WriteDesign Test Release code
  • Towards TDD 1. automated testing Write WriteDesign Test Release code tests
  • Towards TDD 2. test-first development Write WriteDesign Test Release tests code
  • Towards TDD 3. test-driven developmentDesign Write Run Write test test code Release Run Refactor tests
  • Towards TDD3. test-driven development Red Green Refactor
  • Beyond TDD? 4. behaviour-driven development ExecutableCustomer Release examples Red Green TDD Refactor
  • Unit test tools
  • Unit test tools• Java: JUnit, TestNG…
  • Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…
  • Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…• Ruby: Test::Unit, MiniTest, RSpec…
  • Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…• Ruby: Test::Unit, MiniTest, RSpec…• Javascript: JSUnit, JSSpec, Jasmine…
  • Unit test tools• Java: JUnit, TestNG…• C#: NUnit, csUnit…• Ruby: Test::Unit, MiniTest, RSpec…• Javascript: JSUnit, JSSpec, Jasmine…• and many more
  • Acceptance test tools
  • Acceptance test tools• Fit/Fitnesse
  • Acceptance test tools• Fit/Fitnesse• Exactor
  • Acceptance test tools• Fit/Fitnesse• Exactor• Selenium
  • Acceptance test tools• Fit/Fitnesse• Exactor• Selenium• Cucumber
  • Acceptance test tools• Fit/Fitnesse• Exactor• Selenium• Cucumber• Windmill
  • Acceptance test tools• Fit/Fitnesse• Exactor• Selenium• Cucumber• Windmill• etc
  • 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)
  • Acceptance tests Example using Cucumber
  • 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"
  • 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...
  • 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
  • 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
  • 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
  • Unit testsExample using RSpec
  • Unit testsdescribe Calculator do it "can add two numbers" do calculator = Calculator.new calculator.add(2, 3).should eq(" 5") endend
  • Unit tests$ rspec calculator_spec.rbcalculator_spec.rb:1:in `<top (required)>:uninitialized constant Calculator (NameError)
  • Unit testsclass Calculatorend
  • 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
  • Unit testsclass Calculator def add endend
  • 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
  • Unit testsclass Calculator def add a, b endend
  • 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
  • Unit testsclass Calculator def add a, b " #{a + b}" endend
  • Unit tests$ rspec calculator_spec.rb.Finished in 0.00065 seconds1 example, 0 failures
  • 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
  • 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
  • Unit testsclass Calculator def add a, b "%8i" % (a + b) endend
  • Unit tests$ rspec calculator_spec.rb..Finished in 0.00076 seconds2 examples, 0 failures
  • 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
  • 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
  • Unit tests$ rspec calculator_spec.rb..Finished in 0.00075 seconds2 examples, 0 failures
  • 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
  • Unit testsclass Calculator def add a, b "%8i" % (a + b) end def subtract a, b "%8i" % (a - b) endend
  • Unit tests$ rspec calculator_spec.rb...Finished in 0.00085 seconds3 examples, 0 failures
  • Unit testsclass Calculator def add a, b "%8i" % (a + b) end def subtract a, b "%8i" % (a - b) endend
  • 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
  • Unit tests$ rspec calculator_spec.rb...Finished in 0.00086 seconds3 examples, 0 failures
  • 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
  • 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
  • A good test suite…
  • A good test suite…• Expresses the programmer’s intent
  • A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works
  • A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works• Runs quickly
  • A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works• Runs quickly• Gives clear failure messages
  • A good test suite…• Expresses the programmer’s intent• Gives confidence that the system works• Runs quickly• Gives clear failure messages• Is well-maintained
  • 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
  • Benefits of TDD
  • Benefits of TDD• Less manual testing required
  • Benefits of TDD• Less manual testing required• Faster feedback
  • Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer
  • Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer• Shorter cycle time
  • Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer• Shorter cycle time• Reduced rework
  • Benefits of TDD• Less manual testing required• Faster feedback• Safety net to make changes safer• Shorter cycle time• Reduced rework• Improved design
  • What about testers?
  • What about testers?• Less tedious repetitive manual testing
  • What about testers?• Less tedious repetitive manual testing• Concentrate on exploratory testing
  • What about testers?• Less tedious repetitive manual testing• Concentrate on exploratory testing• Identify edge cases and ‘sad path’ tests
  • What about testers?• Less tedious repetitive manual testing• Concentrate on exploratory testing• Identify edge cases and ‘sad path’ tests• Help define acceptance tests
  • How do I start?
  • How do I start?• Greenfield project? JFDI! Otherwise…
  • How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first
  • How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first • Important features
  • How do I start?• Greenfield project? JFDI! Otherwise…• Automate highest value tests first • Important features • Where the most bugs occur
  • 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
  • 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
  • Further reading
  • Discussion