Agile acceptance testing with f sharp
Upcoming SlideShare
Loading in...5
×
 

Agile acceptance testing with f sharp

on

  • 2,549 views

 

Statistics

Views

Total Views
2,549
Views on SlideShare
2,387
Embed Views
162

Actions

Likes
1
Downloads
17
Comments
0

3 Embeds 162

http://skillsmatter.com 122
http://smash 38
http://85.92.73.37 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • This talk is entitled “Automate your Agile Acceptance Tests with F#”. Upon compiling the slides I realised that the message I really wanted to get across is “Verifying software....”, provides loads of value as part of an Agile process if done properly.http://en.wikipedia.org/wiki/Behavior_Driven_Developmenthttp://blog.dannorth.net/introducing-bdd/http://en.wikipedia.org/wiki/Acceptance_testinghttp://gojko.net/resources/whatisfitnesse.pdfhttp://gojko.net/2010/06/16/anatomy-of-a-good-acceptance-test/This talk was
  • Good vs. BadClass names:Description of arrangement for test vs. Name of class being testedState/Arrangement:Set-up state controlled by the setup fun vs. State created for each test inside the test method.Method names:Description of action and expectation vs. Name of method being tested.What is being tested:Behaviour vs. Member functions.
  • http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=13833&tth=DYN&tt=siteemail&iDyn=2Key part here is “A good unit test needs to define the behavioural contract”These kind of observations were what prompted Dan North into evolving TDD into BDD, which is what we will discuss next.
  • Just to re-iterate – language is key to good BDD.We don’t want to be speaking a different language to our stake holders.http://upload.wikimedia.org/wikipedia/en/3/38/Avatarjakeneytiri.jpg
  • This is a description of what BDD is and how it relates to TDD.
  • In an agile process we specify behaviour in terms of stories and acceptance tests.http://en.wikipedia.org/wiki/User_story#Benefits
  • Stories can be vague without acceptance tests, which leaves them open to scope creep.Scenarios are written in the language of business domain, and are as easy for business participants to understand as they are for developers.
  • Allows: - Shared understanding - Diffusion of language into the If the Sapir-Whorf hypothesis is correct and the language you use effects the way you think then this could be very beneficial.
  • This is a small subset of the frameworks available that enable specification execution.There are many frameworks out and they all tend to follow the gherkin style of interpretation.Therefore they are highly interchangeable without having to change your tests.I have used the bottom three on the right. Each time I have made minor adjustments to allow the double-ticked F# methods.Spec Flow seems to be the framework of choice at the moment largely due to it integration with visual studio. It is very good, and I would recommend it. The only gripe I have is that it requires the features to be stored in an assembly, which doesn’t give you much freedom over where you store your files.
  • I was recently working on an extension to our calculations system that is about 5 years old and written in C++. My first concern upon working on the system was that I didn’t break the current behaviour. Theimplementation had no tests of any sort so I had no safety net. And the scenarios I needed to test were fairly complex and not particularly suited to unit testing. I decided to make use of our XML API. Using the API as my interface I was able to build a test client using F# and use BDD to drive it and verify expectations.
  • GojkoAdzicDon Syme

Agile acceptance testing with f sharp Agile acceptance testing with f sharp Presentation Transcript

  • AGILE ACCEPTANCE TESTING WITH F#
    Zach Bray
    2010
  • Outline
    Test Driven Development (TDD)
    Implementing TDD
    Behaviour Driven Development (BDD)
    Implementing BDD
    .NET BDD frameworks
    Case study: Extending a C++ project
  • Test Driven Development (TDD) cycle
  • Unit Tests - Good vs. Bad
  • Unit Testing
    “A good unit test needs both to illustrate and define the behavioral contract of the unit in question. Behavior is more than just individual methods…” – KevlinHenney
  • Na’vi
  • Behaviour Driven Development
    “Is an agile software development technique that encourages collaboration between
    Developers
    QA
    Business Participants
    in a software project.”
    “It extends TDD by writing test cases in a
    natural language that non-programmers can read.”
  • User Stories/Features
    Small chunks of business value.
    Creation and priority driven by stake holders.
  • Acceptance Tests/Scenarios
    Write in the language of the business domain
    i.e., high-level of abstraction
  • Prerequisites for executing scenarios
    Define an interpretable language.
    Domain Specific Language (DSL)
    Ubiquitous language
    Natural language
    Choose a BDD framework
  • The BDD Framework (Unit Test generation)
  • Scenario description line matching example
    Types are tagged as language contexts.
    Each line in the file, e.g.,
    “given a customer buys 2black jumpers”
    Matches a member function.
    Use double-ticked for great readability and DRYness
  • State within scenarios
    In the previous example state was changed inside the language context.
    Contexts are created on a per scenario basis.
    State doesn’t pass through to the next scenario
  • Context Layer: Benefits of F#
    Discriminated Unions & Active Patterns
    Domain Modelling
    Object Expressions
    Implement interfaces
    Terse syntax
    Readability
    Units of measure
    Correctness
    Double ticked method names
    Clear & DRY
    Async Workflows & Agents
    Concurrency
  • BDD Patterns: Templates
    Keeping things DRY with table driven templates.
    Useful for driving many similar test cases.
    given a customer buys a <colour> jumper
    and I have <x> <colour> jumpers left in stock
    when he returns the jumper for a refund
    then I should have <y> <colour> jumpers in stock
    examples:
    | x | y | colour |
    | 1 | 2 | green |
    | 3 | 4 | black |
    | 5 | 6 | red |
  • BDD Patterns: Tables
    Using tables makes data input much more readable.
    Tables are passed into functions.
    given the following bids exist in the Cape/Panamax market
    | qty@price | credit |
    | 1000@ 12.9 | good |
    | 1000@ 12.7 | bad |
    | 800 @ 12.5 | good |
    and the following offers exist in the Panamax market
    | qty@price | credit |
    | 1000@ 12.9 | good |
    when I observe implied orders for the Cape market
    then I should see the following bids
    | qty@price | credit |
    | 1000@ 0.0 | good |
  • BDD Patterns: Templated Tables
    given the following bids exist in the Cape/Panamax market
    | qty@price | credit |
    | 1000@ <price1> | <cred1> |
    | 1000@ 12.7 | bad |
    | 800 @ 12.5 | good |
    and the following offers exist in the Panamax market
    | qty@price | credit |
    | 1000@ <price2> | <cred2> |
    when I observe implied orders for the Cape market
    then I should see the following bids
    | qty@price | credit |
    | 1000@ <calPrice> | <calCred> |
    examples:
    | price1 | price2 | calPrice | cred1 | cred2 | calCred |
    | 1.0 | 1.0 | 0.0 | good | good | good |
    | 1.0 | 0.0 | -1.0 | good | good | good |
    | 2.50 | 2.50 | 0.0 | bad | good | bad |
  • Representation of complex scenarios
    Plain text is dull.
    Rich text is cool.
    It makes the point of the scenario pop out.
    Tables don’t look as ugly!
    Confluence BDD tool
    It downloads features from a Confluence Wiki.
    Then transforms them into executable features.
  • Confluence BDD
  • BDD Patterns: More
    Lots of examples online.
    Search for gherkin.
    Look at http://cukes.info/
  • Benefits of using BDD
    Shared understanding of goals and progress.
    It is independent of the implementation.
    Use the same tests on many implementations.
    Regression suite.
    Nightly regression tests.
    Reduces QA lag at the start of the project.
    QA can start specifying behaviour straight away.
  • Costs of BDD
    Requires more interaction with stake holders.
    Requires more development effort than not testing at all.
  • Costs of not using BDD
    Cost of wrong requirements.
    Cost of poor design.
    Cost of changing implementation and having to refactor all of the tests.
  • The role of Unit Tests
    Primary coverage should come from behaviour specifications.
    Unit Tests should be used pragmatically.
    Documentation
    Edge cases
  • BDD Frameworks
    General
    RSpec
    Cucumber
    JBehave
    JSpec
    etc.
    .Net specific
    NBehave
    Nspec
    Cuke4Nuke
    SpecFlow
    StorEvil
  • SpecFlow: Integrated environment
  • Case Study: Indirect Aggression Project
    Support indirect aggression of implied prices.
    Requires extension to C++ Library.
    Verification is biggest problem.
    Not suited to Unit Tests.
    Behaviour can be tested at API.
    F# made it easy to model the API in few lines.
    Language interpretation was reused.
    Starting to build up a regression suite.
  • Example scenario
  • Example matched function
  • Further Reading