bdd with m spec

21
describing your system one specification at a time

Upload: pavsaund

Post on 25-May-2015

605 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Bdd with m spec

describing your systemone specification at a time

Page 2: Bdd with m spec

Pavneet Singh Saund

t : @pavsaund

l : linkedin.com/in/pavneet

m : [email protected]

w : dolittle.com / blog.dolittle.com

Page 3: Bdd with m spec

Unit testing

Page 4: Bdd with m spec

•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

Test-Driven Development

Page 5: Bdd with m spec

• Where to start?

• What to test?

• What NOT to test?

• How much to test?

• How to name your tests?

• Understanding why tests fail?

... but

Page 6: Bdd with m spec

Behaviour Driven Development

Page 7: Bdd with m spec

•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

What is BDD?

Page 8: Bdd with m spec

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

Page 9: Bdd with m spec

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

Page 10: Bdd with m spec

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

Page 11: Bdd with m spec

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

Page 12: Bdd with m spec

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

Page 13: Bdd with m spec

Specification by example

Page 14: Bdd with m spec

•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

What is BDD?

Page 15: Bdd with m spec

GWT

Given_a_series_of_conditions

When_I_do_something

Then_something_should_happen

//Arrange

//Act

//Assert

Page 16: Bdd with m spec

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! :)

Page 17: Bdd with m spec

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

Page 18: Bdd with m spec

Typical unit test

Page 19: Bdd with m spec

Typical mspec specification

Page 20: Bdd with m spec

DEMO

beware of bugs

Page 21: Bdd with m spec

• MSpec - https://github.com/machine/machine.specifications

• MSpec with Resharper - https://github.com/machine/machine.specifications#resharper

• Context / Specification - http://www.code-magazine.com/article.aspx?quickid=0805061

• http://en.wikipedia.org/wiki/Behavior-driven_development

• http://dannorth.net/introducing-bdd/

• http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/

• Chirp - Bifrost Sample application with MSpec scenarios http://chirp.dolittle.com / https://github.com/dolittle/chirp/

Resources