BDD presentation

Yet Another DD but powerful Behavior Driven Development

Writing software that matters

Temesgen B Meheret (Teme)Senior Software Engineer @ Videology

Email: [email protected]

Background DDs Why do Projects Fail? Writing Software that matters TDD’s promise and it’s shortcomings BDD’s evolution BDD – Second generation agile

methodology Enough Talk, now Code! Summary & Questions

Temesgen B MeheretSenior Software Engineer @Videology

Contents

Writing Software that matters

My name is Temesgen but you can call me “Teme”

Software Engineer and team lead @Videology

Ex-Software Engineer @LCG Plays Ping-Pong Why am I here & not @the Fedexfield for

the USA-Brazil soccer match?

Background

Writing Software that Matters

How many DDs are you aware of?◦ DDD, ATDD, TDD, RDD, MDD…

How many DD belts do you need before to be a great developer?

Driven – Keeping the right order ◦ HAPPY WIFE – HAPPY LIFE

Architecture is Opinion. There are no absolutes. It is really up to us to evaluate and take what applies to our situation.◦ E.g. Aratkilo building architecture

DOUBLE Ds – Don’t U love ‘em?


0 1 2 3 4 5 6 7 8 9 10 11 120

1

2

3

4

5

6

7

Adaptation

Adaptation

Teme’s curve – New Idea adaptation vs. Time (not research based)

Discussion: Selective Unit Testing – Costs and Benefits by Steven SandersonWhere is our team on this curve for BDD?


What are the top 3 things that you believe contribute to a failure of a project?

Have you ever practiced TDD in your projects? If so,◦ Where do you start testing?◦ What did you test?◦ How much did you rely on your tests (trust) during

refactoring? ◦ How effective were your test in terms of detecting bugs?◦ What did you think was the main intent for writing unit

tests?

Points to Ponder


Delivering Late or Over Budget◦ Poor planning, estimation◦ E.g. Deriving requirements from a running application – sheep’s

stomach layers Delivering the wrong thing

◦ Building the product right but not the right product◦ e.g. Projects shelved after many months of development and investment

Unstable in Production◦ E.g. The morning after Deployment hell

Costly to maintain◦ Code Quality

What do you think about asking developers during interviews “How many failed projects have you been part of and what do you think was the cause?”

Writing Software that doesn’t matter – Failed Projects


Cost – Change Exp. Curve(DanNorth.Net)

Discussion points: Top-Down vs. Bottom-up, Civil-Engineering projects vs. Software projectsPractical example: LOE flowing down from Solutions Team, Architecture reviews



In order to achieve this we need to be adaptive in our planning, requirements and design. Regression tests also play a big role to be able to embrace change without fear.

Discussion: Nothing replaces People.

Software development is all about knowing and delivering WHAT MATTERS most to the business

How do you KNOW WHAT MATTERS?Through effective communication!

• Tangible Business Value • Delivered on-time, incrementally• Easy to deploy and manage• Robust in Prod• Easy to understand and communicate

http://thecrispianadvantage.com/2010/08/15/top-down-ro-bottom-up-approaches-to-change/


My Top 5 Must Haves

◦ Clear Communication between Stakeholders Discussion: Stake holders and their world point of

view◦ Constant re-Prioritization owned by the product-

owner◦ Immediate feedback at every level◦ Flexibility – Adapting to Feedback

E.g. client’s needs changed, technology difficulties◦ Working on feature-level


The goal of TDD is specification (Design) and not validation◦ But we always seem to think of TDD as testing tool. We focus on the verification. IMHO clean

code, test assertions and serving as regression suite are all side effects of TDD.◦ Code by example to implement features but when those examples are done then they act as

tests.

What went wrong? Where to start? What to test? What not to test? How much test in one go? What to call the tests? How to understand why a test fails? The focus on testing, vague terms, more focus on units than behavior, tests reflect the

structural arrangement of the codeProgrammers often think "I'm not going to write all those tests.", "It's really simple code, it doesn't need to be tested", "testing is a waste of time", or "I've done this (loop/data retrieval/functionality, etc.) millions of times.".

TDD’s promise and it’s shortcomings


TDD @ different layers• Core Domain Unit

testing (Mocking repo)• MVC unit test (Mocking

domain and app services)

• AppService Unit Test (mocking domain services)

• MVC Acceptance Tests

Our BDD evolution – Though we had so many unit tests, once we push code to QA, we keep getting surprised with scenarios that we never thought about. Then we decided to make QA do test-case reviews at the first week of development. We saw a big value in that which led us to start exploring BDD.


BDD builds on TDD (Discussion: last year presentation) Stripping out the word test and making test methods sentences

Expressive test name is helpful when test fails Behavior is more useful word than test – vocabulary change (Jbehave) Determine the next most important behavior (next thing system doesn’t do) Aha Moment – Requirements are Behavior too!

BDD EvolutionDan North – How it all started


From Testing To Specification. You write specifications of what your code will have to do - “Specification, not Verification” BDD’s definition: "It's about focusing on the behavior of an application from the point

of view of its stakeholders” BDD says you should elevate your mind to a level of behavioral abstraction above

the code implementation.

BDD ◦ is a second-generation, ◦ outside-in, ◦ pull-based, ◦ multiplestakeholder, ◦ multiple-scale, ◦ high automation, agile methodology.

“It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software.”

Discussions: Press releases

BDD’s evolution

BDDUT

UT

UT

UT


TDD - BDD DDD – BDD

◦ Focus on the domain and letting it affect the software very much◦ Ubiquitous language

DDD enables BDD. BDD helps structure the conversations for DDD

ATDD – BDD

◦ "I'd like to avoid "BDD is better than TDD because..." or even "BDD is different from TDD (as originally envisioned) because..." TDD is amazing. Its initial conception was to solve exactly what I've been trying to do with BDD ... It's not the *only* way to come up with good design, and neither is BDD.BDD is about understanding the customer's need and letting emerging understanding of that need drive the software write ... always trying to gain greater understanding. But I bet that's what Kent Beck would say if you asked him what TDD was all about."

BDD – second generation agile methodology

http://www.infoq.com/news/2011/02/BDD-ATDD


Vision – Outcomes – Feature – Stories – Scenarios

Outside - In

User Stories:In order to [business value] As a [role] I

want to [some action]

Scenarios:Given [context]

When I do [action] Then I should see

[outcome]


It is an expression of the customer’s desire It is a Unit of Delivery It focuses on the business value Each story represents part of a feature and belongs to a

stake holder (Stake holders belong to a domain)

Title (one line describing the story)Narrative:As a [role]I want [feature]So that [benefit]Another flavor:In order to [business value] As a [role] I want to [some action]

Outside – In: What is a Story?


You define scope using Scenarios

Scenario 1: TitleGiven [context] And [some more context]..When [event]Then [outcome] And [another outcome]

The GWT fragments can be written using Gherkin language. You just create plain text file “.feature” contain a set of scenario definitions.

Outside – In: Agree on “Done”


Executable Specifications◦ Each step (scenario) is executable◦ Code scenarios by example◦ Examples become code tests and documentation◦ Scenarios become acceptance tests, regression

tests and documentation

Outside In – Automate the Scenarios


Take only what you can consume YAGNI Any more detail is waste, any less is risk

Enough is Enough

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Discussion: Extreme is not good

Pull-based


Anyone who cares about the success of the project is a stake holder◦ Core stakeholders – the ones with the vision◦ Incident Stakeholders – the non-functional

Multiple stake holder


Jbehave (Java) – DanNorth/Chris Matt Rspec (Ruby) Cucubmber (Ruby tool that reads Gherkin) Mspec(Context Specifications) SpecUnit (SetContext,Because of,ItShould) SpecFlow Cucumber Fitnesse Concordion

Tools


BDD is more about a mindset rather than the tools. ASP.NET MVC, Specflow, Nunit, Moq, Autofac

Demo


Easy VS Integration VS Debugger Support Steps can be defined with any .NET language Compiles into a .NET assembly Install SpecFlow.Nunit from NuGet use existing unit-testing frameworks as the runtime for

scenario execution

SpecFlow


Thank you

Any Questions?

work email: [email protected] email: [email protected]

website: http://www.videologygroup.com

mailto:[email protected]

mailto:[email protected]

http://www.videologygroup.com/

The RSpec Book, David Chelimsky http://dannorth.net/introducing-bdd/, Dan

North SPECIFICATION BY EXAMPLE , Gojko Adzik http://

msdn.microsoft.com/en-us/magazine/gg490346.aspx, Brandon Satrom

http://blog.stevensanderson.com/2010/03/03/behavior-driven-development-bdd-with-specflow-and-aspnet-mvc/, Steven Sanderson

Domain Driven Design, Eric Evans User Stories, Mike Cohen

References

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

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

http://msdn.microsoft.com/en-us/magazine/gg490346.aspx



http://blog.stevensanderson.com/2010/03/03/behavior-driven-development-bdd-with-specflow-and-aspnet-mvc/




BDD presentation

Technology

Transcript of BDD presentation