This document discusses Behavior-Driven Development (BDD) using SpecFlow. It explains that BDD uses behaviors instead of tests to validate requirements at different levels. SpecFlow allows automating specifications like unit tests by matching specification lines to step definitions. The document concludes that while BDD and TDD are both useful, the value of BDD is in improving collaboration through a business-focused language and automatically testing specifications.

1. BDD with SpecFlow
Pascal Laurin
February 2015
@plaurin78
pascal.laurin@outlook.com
www.pascallaurin.com
Microsoft C# MVP
MSDEVMTL user group organizer
Developer & Architect at GSoft

2. TDD with B instead of a T!
Somewhat inspired by TDD but using behaviours instead
of tests
What level of behaviours?
Systems level
Applications level
Components level
Classes level
| 2
What is BDD?

3. Unit Tests
Focus on classes
Validate the implementation
Integrated Tests / Functional Tests / Acceptance Tests
Focus on components
Validate behaviours
Systems Tests
Focus on the complete system
Validate the whole system environment including external
dependencies
| 3
Differences between types of
automated tests

4. By changing the level of abstraction and the way we
communicate
Using the language of the business domain
Using sentences to express the expected behaviours
By focusing on what the system under test should do
Requirements, use cases, specifications and behaviours are all
useful for BDD
| 4
How to validate behaviours instead
of tests?

5. Not just for developers
Analysts, QA, business people must also included in this process
Specifications as tests, documentation and collaboration
tool
By automating the specifications like unit tests
By processing specifications as the documentation of the system
By working together on the specifications before writing code
What would a process like that looks like?
| 5
Going further

6. | 6
[1] Specification by Example

7. 1. Deriving scope from goals
2. Specifying collaboratively
3. Illustrating using examples
4. Refining the specification
5. Automating validation without changing specifications
6. Validating frequently
7. Evolving a documentation system
| 7
Specification by Example

8. An example of a good business goal
Increase repeat sales to existing customers by 50% over the next
12 months.
| 8
Business goals

9. User stories for a basic loyalty system
In order to be able to do direct marketing of products to existing
customers, as a marketing manager I want customers to register
personal details by joining a VIP program.
In order to entice existing customers to register for the VIP
program, as a marketing manager I want the system to offer
free delivery on certain items to VIP customers.
In order to save money, as an existing customer I want to receive
information on available special offers.
| 9
Scope

10. Free delivery
VIP customer with five books in the cart gets free delivery.
VIP customer with four books in the cart doesn’t get free delivery.
Regular customer with five books in the cart doesn’t get free
delivery.
VIP customer with five washing machines in the cart doesn’t get
free delivery.
VIP customer with five books and a washing machine in the cart
doesn’t get free delivery.
| 10
Key examples

11. Free delivery
Free delivery is offered to VIP customers once they purchase a
certain number of books. Free delivery is not offered to regular
customers or VIP customers buying anything other than books.
Given that the minimum number of books to get free delivery is
five, then we expect the following:
| 11
Specification with examples

12. Customer type Cart contents Delivery
VIP 5 books Free
VIP 4 books Standard
Regular 10 books Standard
VIP 5 washing machines Standard
VIP 5 books, 1 washing machine Standard
| 12
Specification with examples

13. 1. Deriving scope from goals
2. Specifying collaboratively
3. Illustrating using examples
4. Refining the specification
5. Automating validation without changing
specifications
6. Validating frequently
7. Evolving a documentation system
| 13
Specification by Example

14. 14
SpecFlow
Visual Studio extension, runs like unit tests using any test runner
Write specifications in English with syntax coloring and auto-
completion using the Gherkin[1] language
[1] https://github.com/cucumber/cucumber/wiki/Gherkin

15. 15
SpecFlow
Integrated debugging support
Matching specification lines with step definitions using a RegEx
syntax
Use ScenarioContext.Current and generic Get/Set methods to
store and retrieve test related data between step definitions

16. 16
SpecFlow
Provides code snippet to implement missing step definitions either by
pressing F12 on an unmatched line or by runner the tests

17. 1. Deriving scope from goals
2. Specifying collaboratively
3. Illustrating using examples
4. Refining the specification
5. Automating validation without changing specifications
6. Validating frequently
7. Evolving a documentation system
| 17
Specification by Example

18. | 18
Specification by Example book

19. BDD and TDD
Unit tests, integrated tests and manual tests are all important!
Improving communication
Use business domain language, higher level of abstraction,
avoiding technical vocabulary and implementation details
Requires investment
Good software design practices will help
You won’t necessarily hit the same challenges than with TDD
The real value is in collaboration and automation!
| 19
Conclusion

20. References
[1] Specification by Example
• http://specificationbyexample.com/
SpecFlow
• http://specflow.org/home.aspx
SlideShare of the presentation
• http://www.slideshare.net/PascalLaurin
BitBucket for the code
• https://bitbucket.org/pascallaurin/bdd-talk
@plaurin78
pascal.laurin@outlook.com
www.pascallaurin.com
| 20
Questions?