Knowledge-base
  • Home
  • Samman Technical Coaching
  • Software craftsmanship
    • Practices
      • Pair Programming
      • Code Review
      • Co-designs
      • Design sessions
      • Interview Domain Experts
      • Dev ethics
    • The Software Craftsman
    • Egoless Crafting
    • Technical debt workshop
    • Functional Programming made easy in C# with Language-ext
    • F# for OO programmers
    • Domain Modeling Made Functional
    • Testing
      • Clean Tests
      • Improve the design and testing of your micro-services through CDC Tests
        • CDC testing made simple with Pact
        • Pact broker : the missing piece of your Consumer-Driven Contract approach
      • Improve your test quality with Mutation testing
      • How to name our Unit Tests
      • How to write better assertions
    • Katas
      • TDD
        • Stack kata
        • Fizzbuzz
        • Outside-in TDD (London Style)
      • Improve your software quality with Property-Based Testing
        • A journey to Property-Based Testing
      • Clean Code
      • Clean Architecture
      • Write S.O.L.I.D code
      • Mocking
      • Gilded Rose (Approval Testing)
      • Mikado method
        • Mikado kata
      • Pure functions
      • Theatrical players refactoring Kata
        • Let's refactor (OOP style)
        • Let's refactor (FP style)
      • Functional Programming made easy in Java & C#
      • Refactoring journey
      • Refactoring du Bouchonnois
        • 1) Se faire une idée du code
        • 2) "Treat warnings as errors"
        • 3) Let's kill some mutants
        • 4) Améliorer la lisibilité des tests
        • 5) "Approve Everything"
        • 6) Définir des propriétés
        • 7) Tests d'architecture
        • 8) Use Cases
        • 9) Tell Don't Ask
        • 10) "Avoid Primitives" - Commands
        • 11) "Avoid Exceptions"
        • 12) "Event Sourcing"
    • Software Design X-Rays
      • Workshop
    • The Programmer's Brain
      • How to read code better
  • Software Architecture
    • Fundamentals of Software Architecture
    • Aligning Product & Software Design
    • DDD re-distilled
    • Test your architecture with Archunit
    • NoSQL
  • Agile coaching
    • How to run a Community of Practices (COP)
    • The developers — the forgotten of agility
      • The secrets to re-on-board the devs in agility
    • Coaching toolbox
      • Echelle
      • Learning expedition
    • How to improve Team Decision making ?
      • Decision Making Principles and Practices
    • Learning 3.0
    • Retrospectives
      • Back to the Future
      • Mission Impossible
      • Movie themes
      • Rétro dont vous êtes le héros
      • Sad/Mad/Glad
      • Speed boat
      • Star wars theme
      • Story cubes
    • Technical Agile Coaching with the Samman Method
    • Xanpan - a team centric agile method story
    • XTREM WATCH — Découvrez la puissance de la veille collective
    • Become a better speaker through peer feedback
    • Project-to-Product Principles
  • Leadership
    • Bref. J'ai pris une tarte dans la gueule (et ça fait extrêmement de bien)
    • Forward Summit 2020
    • Learn leadership from the Navy SEALs
    • Learn to lead and help your team(s) to be successful
    • Towards a learning organization and beyond
    • Leadership is language
  • Serious games
    • My serious games
    • Libérez vos entretiens d’embauche avec la gamification
    • How to create a game
    • How to debrief a game ?
    • Lego Serious Play (LSP)
      • LSP in your job interviews
  • Xtrem Reading
    • Cultivate Team Learning with Xtrem Reading
    • My Book Infographics
    • How to make book infographics
    • En route vers l’apprenance avec Xtrem Reading
    • Resources
      • Book notes
        • Agile People: A Radical Approach for HR & Managers
        • Agile testing : A Practical Guide for Testers and Agile Teams
        • Boite à outils de l'intelligence émotionnelle
        • Building a better business using Lego Serious Play method
        • Building evolutionary architectures
        • Code that fits in your head
        • Culture Agile
        • Culture is everything
        • Domain-Driven Design: The First 15 Years
        • Dynamic Reteaming - The Art and Wisdom of Changing Teams
        • How to avoid a Climate Disaster
        • La liberté du commandement
        • Réaliser ses rêves, ça s'apprend
        • Refactoring at Scale
        • Succeeding with OKRs in Agile
        • Team Topologies
        • The Good Life
        • Tu fais quoi dans la vie
        • Who Does What By How Much?
  • My Activity
    • Retour sur mon année 2020
Powered by GitBook
On this page
  • Objectives
  • Connection - 10'
  • Concepts - 10'
  • Use mocks to design the collaborations
  • Concrete Practice - 2h minimum
  • Conclusion - 10'

Was this helpful?

  1. Software craftsmanship
  2. Katas
  3. TDD

Outside-in TDD (London Style)

Kata from Sandro Mancuso

Objectives

  • Learn and practice the double loop of TDD

  • Test application from outside, according to side effect

Connection - 10'

  • What does it bring to design classes as a consumer of the class ?

  • What could it bring to do it in pair ?

  • [Which kind of tool can help you design better software ?] - Optional

Concepts - 10'

In outside-in TDD we only implement what is needed to serve the outside.

  • Write an acceptance test that fails

    • Something that can be accepted by a stakeholder

    • The feature test

  • Keep it red

    • It will indicate what to test

    • Drive to the next step

  • This double loop continues till the feature test turns green

By using this practice :

  • Think about what you want to test in isolation (mocking)

  • Create unit tests

  • What are your test boundaries ?

Use mocks to design the collaborations

The test is used to design the system, and part of that design is deciding how the different components interact / how they are bounds to each others

Concrete Practice - 2h minimum

Here are your instructions :

Create a simple bank application with the following features :

  • Deposit money

  • Withdraw money

  • Print a bank statement to the console

Acceptance criteria

Statement should have the following the format :

DATE       | AMOUNT  | BALANCE
10/04/2014 | 500.00  | 1400.00
02/04/2014 | -100.00 | 900.00
01/04/2014 | 1000.00 | 1000.00

How to start ?

In pair :

  • Start with an acceptance test

  • Use int for money and String for dates

  • Ignore the formatting of the statement for now

Start by designing Service contract

You cannot change the public interface of this class.

public class AccountService {
    public void Deposit(int amount);
    public void Withdraw(int amount);
    public void PrintStatement();
}

As a coach use the Double Loop diagram to demo where the people are.

Sequence Diagram

Introduce the use of Sequence diagram after some time spend on the kata

Use sequence diagram to :

  • Think about how the different objects will collaborate

  • Identify what should be mock and when

Test Driven Development != Test Driven Design

Good design is driven by experience & principles, not by any TDD approach in and of itself.

Take times to reflect on the design outside of the test : great to use diagrams for it

Conclusion - 10'

  • In pair, list all the pros / cons of this Double Loop Approach

  • Share it all together

Resources

    • Sandro Mancuso and Uncle Bob

PreviousFizzbuzzNextImprove your software quality with Property-Based Testing

Last updated 4 years ago

Was this helpful?

Bank kata explained
Sandro Mancuso's implementing the solution
London vs Chicago (video series)
Mocking as a design tool article
Clean architecture through outside-in TDD