Secure your environment with UiPath and CyberArk technologies - Session 1
BDD presentation
1. Writing software that matters
Temesgen B Meheret (Teme)
Senior Software Engineer @ Videology
Email: teme@videologygroup.com
2. 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 Meheret
Senior Software Engineer @Videology
3. 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?
Writing Software that matters
4. 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
Writing Software that Matters
5. Adaptation
7
6
5
4
3 Adaptation
2
1
0
0 1 2 3 4 5 6 7 8 9 10 11 12
Discussion: Selective Unit Testing – Costs and Benefits by Steven
Sanderson
Where is our team on this curve for BDD?
Writing Software that Matters
6. 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?
Writing Software that Matters
7. 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 matters
8. Discussion points: Top-Down vs. Bottom-up, Civil-Engineering projects vs. Software projects
Practical example: LOE flowing down from Solutions Team, Architecture reviews
Writing Software that Matters
9. 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
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.
Writing software that matters
10. ◦ 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
Writing Software that Matters
11. 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 code
Programmers 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.".
Writing software that matters
12. • 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.
Writing Software that Matters
13. 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!
Writing Software that matters
14. 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, UT
◦ outside-in,
◦ pull-based,
◦ multiplestakeholder, UT BDD UT
◦ multiple-scale,
◦ high automation, agile methodology.
UT
“It describes a cycle of interactions
with well-defined outputs, resulting
in the delivery of working, tested
software.”
Discussions: Press releases
Writing software that matters
15. 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."
Writing software that matters
16. Vision – Outcomes – Feature – Stories –
Scenarios
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]
Writing Software that Matters
17. 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]
Writing Software that Matters
18. You define scope using Scenarios
Scenario 1: Title
Given [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.
Writing Software that Matters
19. 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
Writing Software that Matters
20. 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
Writing Software that Matters
21. 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
Writing Software that Matters
23. BDD is more about a mindset rather than the
tools.
ASP.NET MVC, Specflow, Nunit, Moq, Autofac
Writing software that matters
24. 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
Writing Software that Matters
26. 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/b
ehavior-driven-development-bdd-with-
specflow-and-aspnet-mvc/, Steven Sanderson
Domain Driven Design, Eric Evans
User Stories, Mike Cohen