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
  • Connection
  • Concepts
  • Bust the TDD myths
  • 2 TDD schools
  • Concrete Practice
  • 1) Identify your Test Cases
  • How would you name your first test ?
  • How to name Good Unit Tests ? (GUTs)
  • Fizzbuzz Test cases :
  • 2) Once identified the 5 Test Cases, write the code
  • 3) A little bit to easy ?
  • Reflect
  • Conclusion

Was this helpful?

  1. Software craftsmanship
  2. Katas
  3. TDD

Fizzbuzz

Connection

Introduce yourself to a person near you and discuss.

Is it easier to unit test :

- a static method
- pure function
- method that modifies object state
- method that modifies its parameters

The reason for asking about what is easy to test is to get them prepared for designing a pure function or static method for calculating FizzBuzz.

These kinds of functions are easier to test since all the outcomes are visible in the return value, the input value is not modified and there are no side effects.

Concepts

Bust the TDD myths

  • TDD is too Time Consuming

    • The business team doesn’t care at all about the development process you use, as long as it’s effective.

    • TDD will :

      • improve developer productivity (long term)

      • Reduce customer abandonment

      • Reduce the costs of customer service

  • Writing test cases before the code, is not feasible

    • It forces you to have a direction in mind before you start charging into the fray, and having a direction in mind leads to better designs

  • 100% code coverage

    • 100% of testing the wrong things is not a goal…

    • Focus on the value

  • TDD replaces QA

    • We can’t cover everything with TDD

    • For example : GUI E2E tests (really hard to maintain)

    • This is where QA has an important role.

  • Write all tests before we start the code

    • Not at all : 1 test at a time

2 TDD schools

Chicago / Detroit TDD (Classic)

London TDD (Mockist approach)

From the inside to outside

From the outside to inside

Starting from the model classes (Core domain logic)

Use external constraints as a starting point (API endpoint, Services)

No concern for how it might be integrated elsewhere

Concrete Practice

Write a method that returns for a number from 1 to 100 this given number, except that :

  • For multiples of 3 returns “Fizz”

  • For the multiples of 5 returns “Buzz”

  • For numbers which are multiples of both 3 and 5 returns “FizzBuzz”

Let them start for 10' then reflect you can then give them more guidance :

1) Identify your Test Cases

By using the Test Cards in pair : identify test cases

How would you name your first test ?

  • Ask attendees to note on a Sticky Note what is the name of their first test

  • Compare the different styles

  • What do they prefer (Dot voting)

How to name Good Unit Tests ? (GUTs)

Fizzbuzz Test cases :

- shouldReturnTheNumber (ex : 1, 67, 82, ...)
- shouldReturnFizzForMultipleOf3 (ex : 3, 30, 99)
- shouldReturnBuzzForMultipleOf5 (ex : 5, 50, 85)
- shouldReturnFizzBuzzForMultipleOf3And5 (ex : 15, 30, 45)
- shouldThrowAnExceptionForNumberOutOfRange (ex : 0, -1, 101)

2) Once identified the 5 Test Cases, write the code

By using TDD, write Test cases once at a time :

Trap to avoid : "do not write 1 test to rule them all"

  • Talks about sampling

    • Tests are always a sample

    • You cannot cover every possible value

  • Do not repeat the same complexity in your tests than in your Production Code

3) A little bit to easy ?

  • Remove “if” in your code

  • Parameters version, implement this method :

    • If you use a language authorizing default values :

      • int limit : 100

      • int fizz : 3

      • int buzz : 5

public class FizzBuzz {
    public String fizzBuzz(int limit, int fizz, int buzz) {
        ...
    }
}
  • Take a function in parameter

    • Create a Higher Order Function : function modulo(dividend, divisor){ return dividend%divisor; }

  • Add a voice output

  • Write it in an unknown language

Reflect

  • What happened to your code when implementing new tests ?

Triangulation : The more specific tests you write, the more the code will become generic

Conclusion

  • In pairs, discuss how TDD felt, what was difficult and what was easier.

  • Tell the other person the most useful thing you learnt today.

PreviousStack kataNextOutside-in TDD (London Style)

Last updated 4 years ago

Was this helpful?

How to name our Unit Tests