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 - 5'
  • What is a Mock ?
  • In which cases do we use them ?
  • Examples of situation
  • How does it work ?
  • Concrete Practice - 45'
  • How to ?
  • Implement tests - 35'
  • Debrief the exercise - 10'
  • Conclusion - 10'

Was this helpful?

  1. Software craftsmanship
  2. Katas

Mocking

PreviousWrite S.O.L.I.D codeNextGilded Rose (Approval Testing)

Last updated 4 years ago

Was this helpful?

Objectives

  • Understand what is a mock

  • Practice mocking on a code example

Connection - 10'

In groups of 3 answer to this question : in which cases do you use a Mock ?

Concepts - 5'

What is a Mock ?

  • Mock objects allow you to simulate the behavior of classes and interfaces

    • Letting the code in the test interact with them as if they were real

  • Mocks are used to test behavior of other objects, reals, but link to another object not available in test context or not implemented yet

In which cases do we use them ?

Be able to execute tests in isolation

  • Replaces dependency from other object

  • Set expectations on calls to the dependent object

  • Set the exact return values it should give you to perform the test you want

When using mocks you need to always ask yourselves what are your test boundaries.

Examples of situation

  • The system needs a DB access

  • The system call services that are not available

  • The system call APIs developed by other teams which are not implemented yet

How does it work ?

Concrete Practice - 45'

We would like to test a system which convert an amount in a specific currency to another one. The converter method call a service to retrieve the change rate between the two currencies.

Some rules are checked during treatment :

- The amount must be equal or greater than zero
- Service checks if currencies exist
- The service could throw other types of exception following the context
- The return rate must be equal or greater than zero
- The result must be between 0 and the maximum value

In our Unit Tests methods the service is not accessible -> we need to “mock” it

How to ?

  • Demonstrate how to add Mockito to our tests

pom.xml
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>3.3.3</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>3.3.3</version>
    <scope>test</scope>
</dependency>
  • This annotation allows us to use the @Mock annotation (inject Mocks)

@ExtendWith(MockitoExtension.class)
@Mock private ChangeRateService changeRateService;

Implement tests - 35'

  • The production code is implemented as expected

  • Please add the tests to check it

When working with existing code and adding test on it : use your Code Coverage

Debrief the exercise - 10'

  • Group sharing

  • Demo the solution in the dedicated branch

Conclusion - 10'

  • Think about what we did today.

    • If you had to explain the main idea of mocking to someone else, what would you say?

  • Write your explanation in a sentence or two on a post-it

Open the source code

Learn more about it

here
here