4. Test-Driven Development
• Accepted fact that we should test our code
• Tests should cover a single unit
• Each Unit should be driven out by a test (Test-Driven
Development)
• TDD is meant to help drive out the architecture
5. ... but
• Where to start?
• What to test?
• What NOT to test?
• How much to test?
• How to name your tests?
• Understanding why tests fail?
7. What is BDD?
• Term coined by Dan North
• A reaction to confusions and misunderstandings about
Test-Driven Development and how it fits in agile
processes
• An approach to software development that aids to
focus on delivering business value by focus on
behaviour
8. BDD is a second-generation, outside–in, pull-based, multiple-stakeholder,
multiple-scale, high-automation, agile methodology. It describes a cycle of
interactions with well-defined outputs, resulting in the delivery of working,
tested software that matters.
- Dan North 2009
9. BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-
automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting
in the delivery of working, tested software that matters.
• Based on ideas from :
• Extreme Programming
• Lean Software development
• Domain Driven Design
10. BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-
automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting
in the delivery of working, tested software that matters.
• Focusing on specifications that describe the output of the system
• Specifications created Just-in-time and pulled in
11. BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-
automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting
in the delivery of working, tested software that matters.
• Not only just a “user”
• Focus on groups of people that are affected by the system
• ex: end-users, business stakeholders, IT-Operations, other developers..
• Defining and using a ubiquitous language for each groups concerns
12. BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-
automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting
in the delivery of working, tested software that matters.
• Specifications can be described at multiple levels
• Top-level can focus on user-interaction
• Further down can focus on affected areas that fulfill the higher levels
expectations
• Even lower we can focus on technical implementation, still with a solid
focus on the behaviour
14. What is BDD?
• A different way to drive our design (tests)
• Replacing tests with specifications that describe the
behaviour of our system
• “Given When Then” - popularized by Gherkin
• Heavy usage of Mocking to abstract away details
16. MSpec
• Context/Specification framework
• Uses keywords:
Establish context = () =>
Because of = () =>
It should = () >
• Fluent assertions : myresult.ShouldEqual(expected_result)
• You have to accept the lambda syntax! :)
17. MSpec practices
• “Because of = () => “ should only be one line
• “It_should.. = ()=>” should only contain a single assertion
• Re-use contexts by using multiple level of base classes that each have their own
“Establish context = () =>”
• Be consistent with lower_case_naming_of_variables_and_classes - this aids readability
• [Subject()] attribute adds an extra layer of context when “reading” specification ouput
in ex. TestDriven.net
• Can also group behaviours with Behaves_like<> to remove duplicated assertions
