Example mapping applied before writing the first test, workshop

In real life writing tests can be hard and making mistakes is easy, when the business rules are not clear enough.

In a short workshop, we can try a technique closing the gap between a loose specification and the acceptance tests. It is called Example Mapping. This technique was proposed by Matt Wynne from the Behavior Driven Development community. Example mapping helps in understanding the business domain before writing test and code. It allows seeing the unknowns earlier, communicating with business people in the language they understand, prototyping without coding and to save time and efforts by failing and learning fast.

Let us analyze existing business rules and transform them into examples, assumptions, and questions. Later we use our examples to test drive the development. And we get time to share our learnings

Transcript

1. Example mapping applied before writing the first test Dimitry Polivaev (Munich Software Craft Community) Creative Commons Attribution 4.0 International License.
2. “I found during my TDD practice that the bottleneck of TDD is understanding what tests to write.” (Alex Bolboaca)
3. Agenda • Introduction • Example mapping practice • Short retrospective • Coding dojo • Retrospective
4. Example mapping goals • Understand the business domain better before writing test and code. • Identify your questions and assumptions early. • Communicate with business people in their language. • Prototype without coding. • Save time and efforts by failing fast and early. • Shorten user stories for sprints. • Derive your acceptance tests from the examples.
5. Elements https://youtu.be/VwvrGfWmG_U
6. By example: Kata Train Reservation You're working on the “Ticket Office” service, and your next task is to implement the feature for reserving seats on a particular train. There are various business rules and policies around which seats may be reserved. For a train overall, no more than 70% of seats may be reserved in advance, and ideally no individual coach should have no more than 70% reserved seats either. However, there is another business rule that says you must put all the seats for one reservation in the same coach. This could make you and go over 70% for some coaches, just make sure to keep to 70% for the whole train https://bit.ly/2lS0psU
7. Example mapping by example https://youtu.be/VwvrGfWmG_U
8. Element combinations Story Question Rule Rule Example Example Rule Example Assumption Rule Question Example Question Example Story Example Story Rule Rule Question Assumption Example
9. Evaluating example map for different roles “Three amigos” Business Person’s Perspective: • Check if the every relevant piece of information is captured. Dev’s perspective: • Check whether you have everything to start coding and you can finish it during the sprint. Tester’s perspective: • Check whether you have everything to verify that the system works as expected.
10. Evaluating example map by visual indicators Many red cards: The story needs more research and clarification. Many red, blue or green cards inside one story: The story is probably too big. You can add new user story titles on yellow cards. It helps to • split the initial story up, • reduce its scope and complexity, • delay answering some of your questions.
11. Your turn: Kata Theater You work for a theater, and you're working on a suggestion system for seat allocations. During the process of buying tickets, the customer is offered the best seats available in given price range. They will be shown a diagram of the theater with all the available seats shown, and the suggested seats highlighted. The customer will be able to change to different seats if they wish.   You do not need to write the code to display the theater layout with the suggested seats highlighted. You just have to write the code that decides which seats to suggest. Offer seats following these rules, in this order: • Do not offer any seat that is already booked by another customer. • Offer neighboring seats to members of the same party. • Offer seats nearer the middle of a row • Offer seats nearer the stage https://bit.ly/2lwyLBB
12. Your turn: Kata Theater You work for a theater, and you're working on a suggestion system for seat allocations. During the process of buying tickets, the customer is offered the best seats available in given price range. They will be shown a diagram of the theater with all the available seats shown, and the suggested seats highlighted. The customer will be able to change to different seats if they wish.   You do not need to write the code to display the theater layout with the suggested seats highlighted. You just have to write the code that decides which seats to suggest. Offer seats following these rules, in this order: • Do not offer any seat that is already booked by another customer. • Offer neighboring seats to members of the same party. • Offer seats nearer the middle of a row • Offer seats nearer the stage
13. Short retrospective Share • your experiences and impressions, • some questions you got and some assumptions you made, • Some new user stories you suggested or splitted up
14. Test-Driven Development 1. Write a failing test 2. Get it to compile 3. Make it pass 4. Make it clean Unit tests Fail Pass Refactor
15. From example mapping to ATDD “Double loop of Test-Driven Development” Example (informal) Acceptance test (formalized) Unit tests Fail Pass Fail Pass Refactor
16. • “Write just as much test as needed to fail, and each compiler error is a failure”. • “Write just as much code as needed to pass the test”. “Fake it till you make it”. • Over time, the assertions in test get more detailed, and the implementation gets more generic”. Unit tests Fail Pass Refactor Write tests and code in many short iterations Transfer the keyboard to your partner often Go!
17. Retrospective Could you • understand the business domain better before writing test and code? • identify your questions and assumptions early? • communicate with business people in their language.? • prototype without coding? • save time and efforts by failing fast and early? • shorten user stories for sprints? • derive your acceptance tests from the examples? Share your observations, impressions and ideas.