Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Behavior Driven Development - Material de clase PMA

265 views

Published on

Material que he preparado para mis clases en el Postgrado de Metodos Agiles de La Salle. Edicion 2015/2016

Published in: Software
  • Be the first to comment

  • Be the first to like this

Behavior Driven Development - Material de clase PMA

  1. 1. Introducción a BDD Carlos Blé Postgrado de Métodos Agiles - La Salle
  2. 2. Problem Domain Vs Solution Domain Problem SolutionSolution SolutionSolution SolutionSolution WHAT HOW
  3. 3. Solution Domain GUIGUI DatabaseDatabase MockupsMockups PrototypesPrototypes Data StructuresData Structures APIAPI ScreenshotsScreenshots Other appsOther apps ProcessesProcesses
  4. 4. Context & Goals Practices = Principles(Context) (Dan North) Startup company: 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!
  5. 5. 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 ● Gherkin Recommended authors: Gojko Adzic
  6. 6. Specification workshops 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
  7. 7. 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...
  8. 8. 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.
  9. 9. 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
  10. 10. Specification workshops Don't worry about scenarios automation Observe the users interact with our software Meet the users after every release Works for us
  11. 11. What happens with the GUI? UI workshops: 3 Roles: UX, Developer, Analyst User stories often contain GUI “suggestions” or “guidelines” GUI should not add unnecessary constraints
  12. 12. Examples Vs Acceptance Criteria Examples help to understand the business, and remove ambiguity But acceptance criteria requires a higher level of abstraction
  13. 13. 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 ● documentation: the implemented behavior
  14. 14. As garage organiser I want to assign jobs to mechanics To balance the workload in the garage Acceptance Criteria: - 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
  15. 15. Background: “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”
  16. 16. 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 Notes: - Mechanic agenda is stored in table T in the legacy system. UX Suggestions: - Drag & drop could be a good metaphor for the assignments
  17. 17. 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 Acceptance Criteria: - 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.
  18. 18. Recap 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... 7 E AC AC AC E E Heuristic
  19. 19. Separate types of tests Documentation tests - Cucumber - Nunit with specific tags (attributes):         [Test]         [Specification]         public void …() Triangulation tests - Integration and unit tests - Nunit, Webdriver...
  20. 20. Automation Even if we don't automate the scenarios... Cucumber scenarios don't have to be integration tests. Sometimes xUnit/RSpec frameworks are enough. Automation often require little changes in the scenarios... Avoid complex test setup
  21. 21. 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
  22. 22. 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! Release Feedback 10

×