KEMBAR78
Introduction to Testing and TDD | PPTX
INTRODUCTION TO
TESTING
Presented by Sarah Dutkiewicz
sarah@cletechconsulting.com
AGENDA
• What is Testing?
• Test Driven Development – What does this mean?
• Gathering Requirements
• Gherkin
• Tools for TDD in the Workplace
• Testing & Legacy Code
WHAT IS TESTING?
• Identifying as many use cases as possible
• Making sure actual interactions match expected interactions
Extra Lines of Code
More Time to Write
UI Tests
Service Tests
Unit Tests
More integration
More isolation
Slower
Faster
The Test Pyramid - Succeeding with Agile, Mike Cohn
UI Tests
Integration
Unit Tests
More integration
More isolation
Slower
Faster
TEST-DRIVEN – TYPES OF TESTS
Tests, Tests, and More Tests… Oh My!
TYPES OF TESTS
• Unit Tests
• Integration Tests
• Regression / End-to-End Tests
• Performance Tests
• Stress/Load Tests
• Functional Tests
• Acceptance Tests
• Usability Tests
• Manual Testing
• Alpha / Beta Tests
• Exploratory Testing
UNIT TESTS
• Focus on a class or a method
• Tests the smallest unit possible
• Typically tests simple objects; does not
test things such as:
• Database communication
• Network communication
• File system manipulation
INTEGRATION TESTS
• Tests functions, “does things”
• Tests interactions with the outside world, include:
• Database communication
• Network communication
• File system manipulation
• Focused integration tests isolate the testing to one
interaction at a time
• Integration tests should run on their own, with a little
help from 2 fundamental units:
• Setup – run at the beginning of the test to set up
the test environment
• Tear-down – run at the end of the test or upon error
to clean up the test environment
END-TO-END TESTS
• The most brittle of tests – dependent
on the big picture
• Verifies that the unit tests and
integration tests are working like they
should
• Start at the beginning and go through
the whole process
• Includes:
• Acceptance testing
• Functional testing
EXPLORATORY TESTING
• Not an automated process; manual testing
• Sometimes better to go this route rather than end-to-end tests – depending on the
design and architecture of your application
• EXPLORE!
• Discovery
• Investigation
• Learning
WHAT IS
TEST DRIVEN
DEVELOPMENT?
TEST DRIVEN DEVELOPMENT
• Define {something} first through a test
• Write the code to pass the test
• Verify that the test succeeds
• Improve upon the code and keep the test passing
Write the test
Write the
code to pass
the test
Improve the
code while
keeping the
test passing
RED-GREEN-
REFACTOR
EXAMPLE – RUBY KOANS
EXAMPLE – RUBY KOANS
TDD CONCEPT - ASSERTIONS
• Verify whether a certain condition has been met
• Asserts come in many forms:
• (Not) Equal
• Contains / Any
• Is a Type
• Is an Instance of a Type
• Is (Not) Null
• Is (True/False)
• Design Guideline – One assert per test
TDD CONCEPT –
ARRANGE/ACT/ASSERT
• Pattern for arranging a test
1. Arrange all preconditions and inputs.
2. Act on the object or method.
3. Assert that the results have occurred.
CODING KATAS
• Ways to practice testing and TDD
• Good for doing pair programming
• Have someone write the test
• Have someone else write the code to pass the test
DEMO – FIZZBUZZ KATA
Live Coding Example
MORE *-DRIVEN DEVELOPMENT
Related philosophies and methodologies
OTHER RELATED *-DRIVEN
DEVELOPMENT
• Behavior Driven Development
• Acceptance Test Driven Development
• Specification by Example
ACCEPTANCE TEST DRIVEN DEVELOPMENT CYCLE
Discuss the
requirements
Distill the tests in
a friendly format
Develop the
code (and hook
the code to the
tests)
Demo the code
ATDD AND THE TDD CYCLE
Discuss the
requirements
Distill the tests in
friendly format
Develop the code
(and hook the
code to the tests)
Demo the code
RED
GREEN
REFACTOR
GREEN
GATHERING
REQUIREMENTS
The Importance of TDD & ATDD for the UX Realm and an Intro to Gherkin
• Conducted by all who are involved:
• Product owners
• Business analysts
• Developers
• QA
• Requirements are explicitly spelled out.
• Include use cases.
• Include required behaviors or designs.
DISCUSS
GHERKIN
• Common language for gathering requirements
• Written in “plain English” following a particular cadence
• Can then be hooked up to various programming languages and testing tools
• Serves as guidelines for automated tests as well as project documentation
GHERKIN COMPONENTS
• Features
• Scenarios & Scenario
Outlines
• Backgrounds
• Steps
• Multiline Arguments
• Tags
FEATURES
• Define a feature of an application
• Starts with the Feature keyword and contains a few lines to define the feature
Example:
Feature: Short, concise, descriptive text of the goal
In order to do something
As someone related to this system
I want to gain something out of this
* Features are stored in a *.feature file
FEATURE EXAMPLE
Feature: Checking out books
In order to read eBooks on my eBook reader,
As a library patron,
I want to check out eBooks.
SCENARIOS
• Possibilities of situations (scenarios) that apply to a feature
• Scenarios are included in *.feature files with their relevant feature
• Created with one or more steps
SCENARIO EXAMPLE
Scenario: Checking out a book
Given the library collection has the book I want to check out
When I check out the book
Then the library collection’s available count is reduced by 1
STEPS
• Given a certain given condition
• When a certain behavior happens
• Then a certain outcome is expected
• Additional keywords include But and And
• Given a certain given condition
• And another given condition
• When a certain behavior happens
• Then a certain outcome is expected
SCENARIO OUTLINES
• Scenario Outlines eliminate the need for copying and pasting like scenarios and
collapsing values into variables.
• Rather than starting with Scenario, it starts with Scenario Outline.
• Variables (placeholders) are denoted with names sandwiched in greater-than and
less-than symbols.
SCENARIO OUTLINE EXAMPLE
Scenario Outline: Checking book checkout expiration
Given a checkout period of <checkout_period> days
When I open the book at day <open>
Then the book should expire in <left> days
Examples:
| checkout_period | open | left |
| 7 | 2 | 5 |
| 14 | 10 | 2 |
| 21 | 18 | 3 |
MULTILINE ARGUMENTS
• Tables
Example:
Scenario:
Given the following accounts exist:
|name |email |account_type|
| Laura |laura@domain.com | Admin |
| Sarah |sarah@domain.com | Admin |
| Kevin | kevin@domain.com | User |
MULTILINE ARGUMENTS
• Large paragraph of text
Example:
Scenario:
Given a description search with:
" " "
It was the best of times
It was the worst of times
" " "
BACKGROUNDS
• Backgrounds setup the environment for all scenarios in a feature file.
• Starts with the Background keyword and is typically made up of Given, And, and
But clauses
• Runs before individual scenario setup routines
BACKGROUND EXAMPLE
Feature: Checkout eMaterials
Background:
Given a customer named “Sarah Dutkiewicz“
And a library card numbered “12345678901”
And a checkout queue of books:
| title | author |
| Hop on Pop | Dr. Seuss |
| Harold and the Purple Crayon | Crockett Johnson |
| Shark Tales: How I Turned $1,000 into a Billion Dollar Business | Barbara Corcoran|
TAGS
• Used for grouping like tests, scenarios, and/or features together
• Starts with a @, followed by the tag name
Examples:
@UI @accounting @security
• Many test runners support tags and allow collections of tests to be run by tag
DEMO – BOWLING KATA WITH SPECFLOW
SpecFlow Demos at: github.com/techtalk/SpecFlow-Examples
TESTING WITH EXISTING CODE
“WRITE AS YOU GO”
Existing
Code Base
TOOLS FOR TDD IN THE
WORKPLACE
TESTING, GHERKIN LANGUAGE RESOURCES AND
GENERAL TDD RESOURCES
• Ministry of Testing
• Gherkin Language Reference
• The Art of Agile Development: Test-Driven
Development
• Test first != TDD
• Let’s Explore – Exploratory Testing
.NET TDD RESOURCES
• SpecFlow – Behavior Driven Development,
Acceptance Test Driven Development, Specification
by Example; includes support for Silverlight,
Windows Phone, and Mono
• TestDriven.Net – Visual Studio integration for unit
tests
• TestStack.White – UI automation testing
• Visual Studio and Testing Tools
• Nunit
• MbUnit
• NCover
• TypeMock
• Rhino Mocks
JAVASCRIPT TDD RESOURCES
• QUnit
• Jasmine
• Zombie.js
• Mocha
• Chai
RUBY TDD RESOURCES
• Cucumber – behavior driven
development
• Watir – Web Application Testing in
Ruby
• Ruby Koans – learn Ruby via testing
• Rspec – primary Ruby testing tool
JAVA TDD RESOURCES
• JUnit
• Watij – Web Application
Testing in Java
• Mockito
PYTHON TESTING RESOURCES
• Obey the Testing
Goat
• pytest docs
• Python unit testing
with Pytest and
Mock
• The Hitchhiker’s
Guide to Python:
Testing Your Code
ADDITIONAL *DD RESOURCES
• Sahi – JavaScript browser controller
• Selenium – supports C#, Java, Perl,
PHP, Python, Ruby
• Fitnesse – supports multiple
languages
• Canoo WebTest – supports Python,
JavaScript
• TST – the T-SQL Test Tool
CODING KATAS
• Coding Dojo Kata Catalogue
• Soap UI Testing Katas
• CodeKatas.org
• CodeKata.com
• Testing-Challenges.org
CONTACT INFORMATION
Sarah Dutkiewicz
Cleveland Tech Consulting, LLC
sarah@cletechconsulting.com
Twitter: @sadukie
Blog: http://sadukie.com

Introduction to Testing and TDD

  • 1.
    INTRODUCTION TO TESTING Presented bySarah Dutkiewicz sarah@cletechconsulting.com
  • 2.
    AGENDA • What isTesting? • Test Driven Development – What does this mean? • Gathering Requirements • Gherkin • Tools for TDD in the Workplace • Testing & Legacy Code
  • 3.
    WHAT IS TESTING? •Identifying as many use cases as possible • Making sure actual interactions match expected interactions
  • 5.
    Extra Lines ofCode More Time to Write
  • 6.
    UI Tests Service Tests UnitTests More integration More isolation Slower Faster The Test Pyramid - Succeeding with Agile, Mike Cohn
  • 7.
    UI Tests Integration Unit Tests Moreintegration More isolation Slower Faster
  • 8.
    TEST-DRIVEN – TYPESOF TESTS Tests, Tests, and More Tests… Oh My!
  • 9.
    TYPES OF TESTS •Unit Tests • Integration Tests • Regression / End-to-End Tests • Performance Tests • Stress/Load Tests • Functional Tests • Acceptance Tests • Usability Tests • Manual Testing • Alpha / Beta Tests • Exploratory Testing
  • 10.
    UNIT TESTS • Focuson a class or a method • Tests the smallest unit possible • Typically tests simple objects; does not test things such as: • Database communication • Network communication • File system manipulation
  • 11.
    INTEGRATION TESTS • Testsfunctions, “does things” • Tests interactions with the outside world, include: • Database communication • Network communication • File system manipulation • Focused integration tests isolate the testing to one interaction at a time • Integration tests should run on their own, with a little help from 2 fundamental units: • Setup – run at the beginning of the test to set up the test environment • Tear-down – run at the end of the test or upon error to clean up the test environment
  • 12.
    END-TO-END TESTS • Themost brittle of tests – dependent on the big picture • Verifies that the unit tests and integration tests are working like they should • Start at the beginning and go through the whole process • Includes: • Acceptance testing • Functional testing
  • 13.
    EXPLORATORY TESTING • Notan automated process; manual testing • Sometimes better to go this route rather than end-to-end tests – depending on the design and architecture of your application • EXPLORE! • Discovery • Investigation • Learning
  • 14.
  • 15.
    TEST DRIVEN DEVELOPMENT •Define {something} first through a test • Write the code to pass the test • Verify that the test succeeds • Improve upon the code and keep the test passing
  • 16.
    Write the test Writethe code to pass the test Improve the code while keeping the test passing RED-GREEN- REFACTOR
  • 17.
  • 18.
  • 19.
    TDD CONCEPT -ASSERTIONS • Verify whether a certain condition has been met • Asserts come in many forms: • (Not) Equal • Contains / Any • Is a Type • Is an Instance of a Type • Is (Not) Null • Is (True/False) • Design Guideline – One assert per test
  • 20.
    TDD CONCEPT – ARRANGE/ACT/ASSERT •Pattern for arranging a test 1. Arrange all preconditions and inputs. 2. Act on the object or method. 3. Assert that the results have occurred.
  • 21.
    CODING KATAS • Waysto practice testing and TDD • Good for doing pair programming • Have someone write the test • Have someone else write the code to pass the test
  • 22.
    DEMO – FIZZBUZZKATA Live Coding Example
  • 23.
    MORE *-DRIVEN DEVELOPMENT Relatedphilosophies and methodologies
  • 24.
    OTHER RELATED *-DRIVEN DEVELOPMENT •Behavior Driven Development • Acceptance Test Driven Development • Specification by Example
  • 25.
    ACCEPTANCE TEST DRIVENDEVELOPMENT CYCLE Discuss the requirements Distill the tests in a friendly format Develop the code (and hook the code to the tests) Demo the code
  • 26.
    ATDD AND THETDD CYCLE Discuss the requirements Distill the tests in friendly format Develop the code (and hook the code to the tests) Demo the code RED GREEN REFACTOR GREEN
  • 27.
    GATHERING REQUIREMENTS The Importance ofTDD & ATDD for the UX Realm and an Intro to Gherkin
  • 28.
    • Conducted byall who are involved: • Product owners • Business analysts • Developers • QA • Requirements are explicitly spelled out. • Include use cases. • Include required behaviors or designs. DISCUSS
  • 29.
    GHERKIN • Common languagefor gathering requirements • Written in “plain English” following a particular cadence • Can then be hooked up to various programming languages and testing tools • Serves as guidelines for automated tests as well as project documentation
  • 30.
    GHERKIN COMPONENTS • Features •Scenarios & Scenario Outlines • Backgrounds • Steps • Multiline Arguments • Tags
  • 31.
    FEATURES • Define afeature of an application • Starts with the Feature keyword and contains a few lines to define the feature Example: Feature: Short, concise, descriptive text of the goal In order to do something As someone related to this system I want to gain something out of this * Features are stored in a *.feature file
  • 32.
    FEATURE EXAMPLE Feature: Checkingout books In order to read eBooks on my eBook reader, As a library patron, I want to check out eBooks.
  • 33.
    SCENARIOS • Possibilities ofsituations (scenarios) that apply to a feature • Scenarios are included in *.feature files with their relevant feature • Created with one or more steps
  • 34.
    SCENARIO EXAMPLE Scenario: Checkingout a book Given the library collection has the book I want to check out When I check out the book Then the library collection’s available count is reduced by 1
  • 35.
    STEPS • Given acertain given condition • When a certain behavior happens • Then a certain outcome is expected • Additional keywords include But and And • Given a certain given condition • And another given condition • When a certain behavior happens • Then a certain outcome is expected
  • 36.
    SCENARIO OUTLINES • ScenarioOutlines eliminate the need for copying and pasting like scenarios and collapsing values into variables. • Rather than starting with Scenario, it starts with Scenario Outline. • Variables (placeholders) are denoted with names sandwiched in greater-than and less-than symbols.
  • 37.
    SCENARIO OUTLINE EXAMPLE ScenarioOutline: Checking book checkout expiration Given a checkout period of <checkout_period> days When I open the book at day <open> Then the book should expire in <left> days Examples: | checkout_period | open | left | | 7 | 2 | 5 | | 14 | 10 | 2 | | 21 | 18 | 3 |
  • 38.
    MULTILINE ARGUMENTS • Tables Example: Scenario: Giventhe following accounts exist: |name |email |account_type| | Laura |laura@domain.com | Admin | | Sarah |sarah@domain.com | Admin | | Kevin | kevin@domain.com | User |
  • 39.
    MULTILINE ARGUMENTS • Largeparagraph of text Example: Scenario: Given a description search with: " " " It was the best of times It was the worst of times " " "
  • 40.
    BACKGROUNDS • Backgrounds setupthe environment for all scenarios in a feature file. • Starts with the Background keyword and is typically made up of Given, And, and But clauses • Runs before individual scenario setup routines
  • 41.
    BACKGROUND EXAMPLE Feature: CheckouteMaterials Background: Given a customer named “Sarah Dutkiewicz“ And a library card numbered “12345678901” And a checkout queue of books: | title | author | | Hop on Pop | Dr. Seuss | | Harold and the Purple Crayon | Crockett Johnson | | Shark Tales: How I Turned $1,000 into a Billion Dollar Business | Barbara Corcoran|
  • 42.
    TAGS • Used forgrouping like tests, scenarios, and/or features together • Starts with a @, followed by the tag name Examples: @UI @accounting @security • Many test runners support tags and allow collections of tests to be run by tag
  • 43.
    DEMO – BOWLINGKATA WITH SPECFLOW SpecFlow Demos at: github.com/techtalk/SpecFlow-Examples
  • 44.
  • 45.
    “WRITE AS YOUGO” Existing Code Base
  • 46.
    TOOLS FOR TDDIN THE WORKPLACE
  • 47.
    TESTING, GHERKIN LANGUAGERESOURCES AND GENERAL TDD RESOURCES • Ministry of Testing • Gherkin Language Reference • The Art of Agile Development: Test-Driven Development • Test first != TDD • Let’s Explore – Exploratory Testing
  • 48.
    .NET TDD RESOURCES •SpecFlow – Behavior Driven Development, Acceptance Test Driven Development, Specification by Example; includes support for Silverlight, Windows Phone, and Mono • TestDriven.Net – Visual Studio integration for unit tests • TestStack.White – UI automation testing • Visual Studio and Testing Tools • Nunit • MbUnit • NCover • TypeMock • Rhino Mocks
  • 49.
    JAVASCRIPT TDD RESOURCES •QUnit • Jasmine • Zombie.js • Mocha • Chai
  • 50.
    RUBY TDD RESOURCES •Cucumber – behavior driven development • Watir – Web Application Testing in Ruby • Ruby Koans – learn Ruby via testing • Rspec – primary Ruby testing tool
  • 51.
    JAVA TDD RESOURCES •JUnit • Watij – Web Application Testing in Java • Mockito
  • 52.
    PYTHON TESTING RESOURCES •Obey the Testing Goat • pytest docs • Python unit testing with Pytest and Mock • The Hitchhiker’s Guide to Python: Testing Your Code
  • 53.
    ADDITIONAL *DD RESOURCES •Sahi – JavaScript browser controller • Selenium – supports C#, Java, Perl, PHP, Python, Ruby • Fitnesse – supports multiple languages • Canoo WebTest – supports Python, JavaScript • TST – the T-SQL Test Tool
  • 54.
    CODING KATAS • CodingDojo Kata Catalogue • Soap UI Testing Katas • CodeKatas.org • CodeKata.com • Testing-Challenges.org
  • 55.
    CONTACT INFORMATION Sarah Dutkiewicz ClevelandTech Consulting, LLC sarah@cletechconsulting.com Twitter: @sadukie Blog: http://sadukie.com

Editor's Notes

  • #2 Introduction to Test Driven Development (For Both Developers and Non-Developers) Have you heard of Test Driven Development (TDD) and wondered exactly what it meant? In this talk, we'll explore the process of Test Driven Development and how it fits in with gathering user needs and requirements. If teams know how they fit together, it can be a beautiful thing. Using gherkin (written in plain English that follows a pattern) to express the user needs and app requirements, developers can then write tests that lead to code that eventually lead to improvement in the overall software development process. We will also explore some tools for various platforms that can be used in the TDD process.
  • #6 Save your bacon in finding issues with updates before they make it to production. Let’s talk about the parts to testing and the “why” will be more clear.
  • #10 Image taken from: http://2.bp.blogspot.com/_1UIyN-eAGC8/SnoFcKZ9gtI/AAAAAAAABnQ/rLOduxwJKmo/s320/point+d%27interrogation.jpg
  • #11 Image taken from: http://upload.wikimedia.org/wikipedia/commons/f/fd/Light_Green_Lego_Brick.jpg
  • #12 Image taken from: http://pixelperfectdigital.com/samples/NDQ0YzczNWFhODVlMw==/MjJjNzM1YWE4NWUz/photo.jpg&size=1024
  • #15 Image taken from: http://onproductmanagement.net/wp-content/uploads/2010/10/why-us.jpg
  • #17 This may also be known as Red-Green-Clean
  • #25 Related reading: http://janetgregory.blogspot.com/2010/08/atdd-vs-bdd-vs-specification-by-example.html
  • #29 This is the Discuss phase of the Discuss/Distill/Develop/Demo cycle.
  • #31 Image taken from: http://2.bp.blogspot.com/-Q8TsaBzcxxg/TchwA0vS_sI/AAAAAAAAAEY/dMbBux1SukI/s320/lego+pile.jpg