LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
Behavior Driven Development - Material de clase PMA
Introducción a BDD
Postgrado de Métodos Agiles - La Salle
Problem Domain Vs Solution Domain
Data StructuresData Structures
Other appsOther apps
Context & Goals
Practices = Principles(Context)
Don’t even know its market!
The goal is to learn about customers
Tailored software tools:
The problem is well-known
Business doesn’t change often!
Problem discovery tools
Examples, examples, examples!
A deep understanding of the business is a must
● Specification workshops
● Impact mapping
● Mind maps
● User stories
● User story mapping
● Example mapping
● Event Storming
Recommended authors: Gojko Adzic
1.Conversation with examples (no Gherkin)
2.Acceptance criteria definition.
3.Write down some scenarios.
4.Refine the scenarios (sometimes Gherkin).
5.Remove redundant examples/scenarios.
The Three Amigos
Separate the “What” from the “How”
The way to go fast is to avoid waste
Everything seems to be solved with CRUD... but in the
end it’s pretty much never a CRUD!
Every line of code is a commitment
Defer implementation details as much as you can.
Reverse engineering is sometimes required to discover
the problem from the solution
Known or proposed solutions are welcome as long as...
Works for us
Short user stories we can develop in two days.
Vertical user stories.- non-explicit technical stuff
Business valuable examples. - no state
Separate acceptance criteria from scenarios.
Deliver new features every week or two weeks.
Direct access to each other to ask
questions face to face at any time.
Hexagonal Architecture (ports & adapters)
Combine Cucumber with other
tools (xUnit, RSpec flavored frameworks)
Mind maps: plan and prioritize
Works for us
Don't worry about scenarios
Observe the users interact with
Meet the users after every release
Works for us
What happens with the GUI?
3 Roles: UX, Developer, Analyst
User stories often contain
GUI “suggestions” or “guidelines”
GUI should not add unnecessary
Examples Vs Acceptance Criteria
But acceptance criteria requires a higher level of
See the forest for the trees
Acceptance criteria are a quick summary
to help us understand...
● what do we really want?
the desired behavior of the system
● how to demo?
when is the feature done
the implemented behavior
As garage organiser
I want to assign jobs to mechanics
To balance the workload in the garage
- Jobs are assigned to a single mechanic on a particular
day without specifying the start time
- Jobs have different priorities
- Ongoing jobs can't be assigned from one
mechanic to another
- A finished job can't be assigned to
any other mechanic
“Paco” is a mechanic
Scenario: Assign job to mechanic
Given the job "Change pad brakes" is in the unassigned work queue
And “Paco”'s agenda for tomorrow is empty
When the organizer assigns the job to “Paco” for tomorrow
Then the first thing for him to work on tomorrow is that job
And the job is no longer in the unassigned work queue
Scenario: Prioritize jobs
Given “Paco”'s queue for tomorrow contains "Change oil" & “Inspection”
When the organizer prioritizes the job “Inspection” for “Paco”
Then first thing for him to work on tomorrow is “Inspection”
Scenario: Ongoing jobs can't be reassigned
Given that “Paco”'s is working on "Inspection”
When the organizer tries to assign the job to another mechanic
Then the organiser is told that “Paco” is already working on that job
And it remains assigned to “Paco”
Scenario: Finished jobs can't be reassigned
Given that “Paco” is done with job “Change pad brakes”
When the organiser tries to assign it to another mechanic
Then the organiser is told that job is finished and can't be reassigned
- Mechanic agenda is stored in table T in the legacy system.
- Drag & drop could be a good metaphor for the assignments
Do we need scenarios for this one?
As garage organiser
I need to know what jobs are in the queue
To assign jobs to mechanics
- Jobs are in the queue when:
- they are not assigned to a particular mechanic
and the car is in the garage.
- the job doesn't require a pending steering part.
Acceptance criteria specify what should be done
Examples help understand the criteria
Additional information may be useful
When an acceptance criterion is a long line...
When an example doesn't reveal the criterion...
Separate types of tests
- Nunit with specific tags (attributes):
public void …()
- Integration and unit tests
- Nunit, Webdriver...
Even if we don't automate the scenarios...
Cucumber scenarios don't have to be
Sometimes xUnit/RSpec frameworks are
Automation often require little changes in the
Avoid complex test setup
Green field Vs Legacy
Test-first let us aim for the best design.
Perfect for green field projects.
Test-first does not help much when a big chunk
of the system is already designed though
We love feedback!
Features are not real until they go live and
users embrace them. Don't plan too far away!
Conclusion: listen to your users!