SpecFlow for Agile Teams
•Download as PPTX, PDF•
1 like•617 views
SpecFlow is an automated testing tool that allows teams to write acceptance tests in a behavior-driven development (BDD) style using the Gherkin language. It is used with .NET projects and runs tests written in plain English describing features and scenarios. SpecFlow generates code stubs from Gherkin features that testers then implement to automate the scenarios. This allows development and testing teams to collaborate using a shared language to define requirements and ensure they are met through automated acceptance tests.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to SpecFlow for Agile Teams
Similar to SpecFlow for Agile Teams (20)
Recently uploaded
Recently uploaded (20)
SpecFlow for Agile Teams
- 1. SpecFlow for Agile Teams Alejandro Ramirez Senior Consultant Polaris Solutions
- 2. Platinum Sponsors Silver Sponsors Gold Sponsors
- 3. The evolved role of testing Image credit: http://www.archeolog-home.com/pages/content/how-humans-became-masters-of-the-earth.html Black-Box Agile
- 4. Test automation pyramid GUI Tests Acceptance Tests Unit Tests Manual Tests
- 5. Test automation pyramid GUI Tests Acceptance Tests / BDD | ATDD Unit Tests / Component Tests/ TDD Manual Tests CodedUI Visual Studio SpecFlow Visual Studio xUnit Visual Studio Manual Test Cases Exploratory Tests MTM Agile Maturity
- 6. ATDD or BDD? They are the same thing! Agile techniques Started in 2003 Understanding software behavior through discussion Discussing acceptance criteria with examples Focus on why and benefits of code Embodies the definition of done in tests Image is copyright of Nintendo https://microsite.nintendo-europe.com/Stay_Updated/ptPT/
- 7. What is SpecFlow? Not a pickle Automated testing tool Runs acceptance tests written in BDD style It’s Cucumber for .NET
- 8. What you need to use it • Visual Studio • SpecFlow package • Learn Gherkin
- 9. How to use SpecFlow in 3 Steps ONE: Specify behavior in Gherkin TWO: Automate scenarios THREE: Enjoy and repeat
- 10. Example( y o u a r e g o i n g t o l o v e i t )
- 11. Specifying behavior with Gherkin Describe behavior in plain English Given, When, Then In order to, As a, I want to Feature Behavior
- 12. Feature: Add Customer In order to store new customer information As a User of the XYZ system I want to be able to create and store new customers
- 13. Scenario 1: Happy Path Given a user has entered information about a customer When he/she completes entering more information Then the customer information should be stored in the system
- 14. Scenario 1 (more elaborate) Given a user has entered information about a customer And he/she has provided a first name and a last name When he/she completes entering more information Then the customer information should be stored in the system
- 15. Scenario 1 (even more elaborate) Given a user has entered information about a customer And he/she has provided a first name and a last name When he/she completes entering more information Then the customer information should be stored in the system
- 16. Scenario 1 (even more elaborate) Given a user has entered information about a customer And he/she has provided a first name and a last name When he/she completes entering more information Then the customer information should be stored in the system
- 17. Scenario 2: Missing Required Data Given a user has entered information about a customer And he/she has not provided the first name and last name When he/she completes entering more information Then the user will be notified about the missing data And the customer will not be stored into the system
- 18. Exercise
- 19. In real life:
- 20. Quick Demo
- 21. Automating behaviors Generate stubs Fill in the blanks Run
- 22. SpecFlow approaches for agile teams Service layer Integration GUI
- 23. SpecFlow approaches for agile teams Dev + BA Dev + Test + BA Dev + Test
- 24. Do you want to know more? Contact: alejandro.ramirez@polarissolutions.com @alejandrormz www.polarissolutions.com
- 25. Q&A
Editor's Notes
- Evolution: Talk about how testers have been perceived through time. Dream come true: testing as a first-class citizen in agile. Team Members: Talk about how in agile is all about “roles”, and not so much about a “Tester” or “Developer”, but the skills they bring to the table
- Unit Testing and TDD: MSTest, NUnit Executable Specifications and BDD: SpecFlow UI Automation: CodedUI ES/SBE An executable specification is a description of software behavior written in natural language, but with a defined structure. A.K.A. Behavior-Driven Development (BDD) Acceptance-Test-Driven-Development (ATDD) Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket. CodedUI requires: Visual Studio Premium or Ultimate Edition (CodedUI Test Project) Pitfalls Trying to do everything UI should be last resort When should I use UI testing? Test the things that are only possible from the UI Navigation The way the user interacts Stuff you can't test from Unit tests When not? Validating business rules ONLY TEST THINGS YOU CANNOT TEST WITH UNIT TESTS 3 Ways to use CodedUI Record & Playback (most common) Great way to get started Not the way to get the most ROI Most fragile way to build your test automation Be careful of multiple team members recording at the same time and merging the UIMap files One big chunk of unmaintainable code Use Recording of UI Maps to abstract the UI and then code against the abstraction More maintainable Be careful about maintaining UI Map files Create multiple UI maps, each one targeting a specific part of your UI Record ACTIONS and ASSERTIONS in separate UIMap Files Hand code everything and not use UI Map files Most control Most time-consuming Use UI Maps only for specific purposes like locating controls Create a UI Map per distinct par of the UI Requires more coding Page Object Pattern Helps you abstract the details of HOW the UI is CONSTRUCTED We create a class that represents the screen we see when we browse a web page, and we represent those UI elements as objects. Each Page Object abstracsts a PAGE or a PART OF A PAGE The Page Object has knowledge of the page and has the ability to find controls within the page. A Page Object has Methods Provides services to the test developer Abstracts the way UI elements are located Returns page objects A Page Object has Query Methods Used in assertions so deails about the UI stay with the object and don't leak to your test E.G. IsPageValid() os IsItemInShoppingBasket("name of item") Assertion is done in the test!
- Cucumber is a software tool that computer programmers use for testing other software. It runs automated acceptance tests written in a behavior-driven development (BDD) style. Specification by Example An executable specification is a description of software behavior written in natural language, but with a defined structure. Cucumber is written in the Ruby programming language.[6][7] Cucumber projects are available for other platforms beyond Ruby. Some use Ruby Cucumber with a bridge into the target language (e.g. cuke4php and cuke4lua). Others use the Gherkin parser but implement everything else in the target language.[8] Cucumber allows the execution of feature documentation written in business-facing text.
- Talk about the work that goes into Test Planning Sprint Planning vs. Poker Planning
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Talk about the work that goes into Test Planning Sprint Planning vs. Poker Planning
- Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. Gherkin uses GIVEN/WHEN/THEN structure that lets you write specifications like this: GIVEN that I have items in my basket, WHEN I go to the checkout, THEN I am shown a confirmation screen, AND the screen lists all the items in my basket.
- Talk about the work that goes into Test Planning Sprint Planning vs. Poker Planning