Embed Size (px)
DESCRIPTION
Learn how Acceptance Test Driven Development (ATDD) provides the process for capturing detailed requirements as acceptance criteria and turn them into as test cases before development begins using Behavior Driven Development (BDD). The BDD approach and Gherkin format is the language used to create easy to understand and actionable scenarios that map from the functional level to the components and units. We will discuss the different approaches to TDD including a realistic approach leveraging BDD to a purest standpoint where TDD use the tests to drive the design of the application. Finally understand how the tools in Visual Studio and Team foundation Server to support BDD such as SpecFlow (Cucumber in .NET), Refactoring tools, and Test Cases in MTM.
Citation preview
Acceptance Test Driven DevelopmentMike DouglasMikedouglas *AT* Deliveron.com@mikedouglasdev
Kim DietzKimdietz *AT* Deliveron.com
ABOUT DELIVERONDeliveron is a project-based consulting organization that delivers business-driven technology solutions. Our high success rate is the result of our:
• Team approach with client engagements• Integrated client partnership and collaboration• Deep expertise in core Microsoft technologies• Project leadership and guidance• Agile delivery framework and ALM best practices• Strategic offerings
We provide solutions across five primary areas:• Custom Application Development using
Microsoft Technologies• Portals, Workflow, Collaboration, and
Enterprise Social• Cloud and Hybrid Platforms• Enterprise Application Integration • Analytics and Business Intelligence
Nebraska Code Camp Gold Sponsor
Acceptance Test Driven DevelopmentMike [email protected]@mikedouglasdev
AGENDA• What is Agile Testing?• Differentiating TDD, ATDD, and BDD• Why use ATDD?• Understanding the Process
WHAT IS AGILE TESTING?• Traditional / Waterfall– Huge Word documents, well protected– Documents don’t work so well…• Too expensive = time to create and maintain• What if the unspeakable happens…There’s a change!?!• Out of date as soon as it is signed off• Can’t use to prove the intent of the spec is met• No run / test button in Word
WHAT IS AGILE TESTING?• Traditional / Waterfall– Waiting until development is complete• Testing time is often compressed because development
took longer than planned• Typically this is the first time the users get to see the
application• Usually what they asked for, less often it is what they
want
WHAT IS AGILE TESTING?• Agile
– We have user stories…• Expressing desirements• User stories represent needed conversations• User Stories are the requirements, but only until done,
done.– Need something to document that the conversation took place
• Written as the functionality is now done and this is how it should work
• Testable outcome can be verified• To become executable specifications
TDD, ATDD, AND BDD
TDD, ATDD, AND BDD• 2 levels of Test First Development– TDD (Test Driven Development)– ATDD (Acceptance Test Driven Development)
Create failing Unit Test
Make the test pass
Refactor
Unit / Component
TDD, ATDD, AND BDD ATDD TDD
Convert to Scenarios
Create failing Acceptance Test
Make the test pass
For each Scenario
Capture Acceptance Criteria
Create User Story
Verifiable Working Software
TDD, ATDD, AND BDD• TDD – Developer focused – Unit / Component Level– Validates “building the code right”– “Encourages simple designs and inspires software” - Kent
Beck – Usually tests code in isolation (Dependency Injection and
Mocking frameworks)– Advantages• Enables you to take small steps when writing software• Prevents gold plated software
TDD, ATDD, AND BDD• TDD – General Steps• Red -> Green -> Refactor
– Write a failing Test– Write the code to make the test pass– Refactor code and know you didn’t break any functionality
TDD, ATDD, AND BDD• TDD Demo– Dependency Injection• Ninject
– Mocking Framework• Moq
TDD, ATDD, AND BDD• ATDD
– Acceptance level or functional level– Validates “building the right code”– Executable Specifications
• Expressing requirements such that they are also executable tests• Word can’t prove software works• Meaningful to business, testers, and developers
– General Steps• Acceptance Criteria• Convert to Executable Requirement / Test Case• In Parallel
– Dev - Write Code to make tests pass– Testing - Manually Test and Pass
TDD, ATDD, AND BDD• Scenarios– Executable acceptance criteria– Gherkin• Format to capture conversations with business• GIVEN – some context…• WHEN – some action is performed…• THEN – some result can be verified…
TDD, ATDD, AND BDD• BDD– Behavior Driven Development– Specific implementation of ATDD / TDD using Gherkin
language– Creates the executable scenario with automated tests– Dependent on a tool such as Cucumber for Java/Perl
(others) or SpecFlow for .NET– Functional level (xBehave) or developer level (xSpec)
TDD, ATDD, AND BDD• BDD Tools– Functional written by team – SpecFlow or NBehave– Developer level – Nspec
• SpecFlow– Integration with Visual Studio
Visual Studio Extensions Project NuGet Packages
Create failing Unit Test
Make the test pass
Refactor
Unit / Component
TDD, ATDD, AND BDD ATDD TDD
Convert to Scenarios
Create failing Acceptance Test
Make the test pass
For each Scenario
Capture Acceptance Criteria
Create User Story
Verifiable Working Software
Can do ATDD and TDD separately or together
WHY ATDD?• Test maintainability
– Refactor code with minimal impact on the tests
• Avoid misunderstood requirements– Common language so that business, testers, and developers can better
understand the requirements
• Automated regression testing is delivered as part of the project– Automated Executable Specifications
• Reporting of ATDD progress – Provides great insight of progress during Sprints
• Testing the functionality that has been requested– Preventing the gold plated code
UNDERSTANDING THE PROCESS• Customer Maintenance application
UNDERSTANDING THE PROCESS• Requirement Definition (User Story Statement)– UINVEST• U = Understandable – story must make sense• I = Independent – self contained• N = Negotiable – can be changed until added to an
iteration• V = Valuable – deliver value• E = Estimatable – estimate a size of the story• S = Small – stories should not be too big• T = Testable – we must be able to test it
UNDERSTANDING THE PROCESS• Requirement Definition (User Story Statement)– Role, Goal & Reason
UNDERSTANDING THE PROCESS• How to Define Acceptance Criteria (Definition of
Done)– Defined for each User Story during the Iteration Planning
meeting– Conditions that must be met to consider the Story “Done”• Includes Functional & Non-Functional Requirements
– High level definition of what is acceptable and what is not– Actionable in order to translate into Test Case(s)– Either everything is “Done” or the Story is incomplete
UNDERSTANDING THE PROCESS• How to Define Acceptance Criteria (Definition of
Done)
UNDERSTANDING THE PROCESS• Converting Acceptance Criteria to Scenario/Test Case
– Test Case creation for each User Story takes place during the Iteration Planning or Iteration Definition meeting
– Involves the Development Team and the Business– Test Cases are the executable specifications of the
Acceptance Criteria– Gherkin
• Format to capture conversations with business• GIVEN – some context…• WHEN – some action is performed…• THEN – some result can be verified…
UNDERSTANDING THE PROCESS• Implementing test cases as part of the development
process– Developer creates the failing SpecFlow tests– BA/QA defines the test case steps, input values and
expected outcomes that will be used for the execution of the test cases
UNDERSTANDING THE PROCESS• Implementing test cases as part of the development
process– Developer makes the appropriate code changes until the
SpecFlow scenario passes– The Developer updates the User Story state to Resolved
and the BA/QA executes any remaining manual test cases – When all test cases are in a Passing state, the User Story is
then handed off to the appropriate business user to complete UAT and Close the User Story.
UNDERSTANDING THE PROCESS• Results Reporting– TFS Test Plan Status Report
UNDERSTANDING THE PROCESS• Regression Tests Delivered During Iteration– Not only has the Team delivered the User Story, they now
also have a repository of regression test cases!– Benefits the team whether the Test Cases are Automated
or executed manually.
UNDERSTANDING THE PROCESS• BA/QA Demo– User Story in Visual Studio• Linked Test Cases
– Open MTM• Iteration Test Plans
– Test Suites– Test Cases
UNDERSTANDING THE PROCESS• Developer Demo– Functional Tests• In Process• Easy to Mock• Fast, bypass UI
– Coded UI Test• Out of process• Test against live site• Tests UI• Page Object Pattern
UNDERSTANDING THE PROCESS• Options– QA members replacing their manual testing with writing
SpecFlow tests– Linking between the test cases and automated provide
automation from Test Manager– Automated Tests can be run as part of nightly
UNDERSTANDING THE PROCESS• Call to Action– Try ATDD in your process– Try TDD in your process– Let us know if you would like any help or have questions– Let us know if you want us to come talk to your teams
1 1 5 1 6 M i r a c l e H i l l s D r i v e S u i t e 2 0 1 O m a h a , N E 6 8 1 5 4
4 0 2 . 2 3 8 . 1 3 9 9 | w w w . d e l i v e r o n . c o m | c o n t a c t u s @ d e l i v e r o n . c o m
