Testing Mastery: JUnit, Mockito & Integration Tests · Leçon

Objets simulés, bouchons et doublures

Distinguez les différents doubles de test : objets simulés, bouchons, doublures et objets factices, et comprenez leur rôle dans les tests.

Objets simulés, bouchons et doublures est une leçon Testing Mastery: JUnit, Mockito & Integration Tests gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Testing Mastery: JUnit, Mockito & Integration Tests, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Testing Mastery: JUnit, Mockito & Integration Tests comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

What are Test Doubles?

When testing a class, it often depends on other classes. These "dependencies" can make tests tricky! Test doubles are stand-in objects that mimic the behavior of real dependencies.

They help isolate the code you're testing, making your tests faster, more reliable, and easier to write.

Why Do We Need Them?

Imagine testing a class that sends emails or talks to a database. You don't want your tests to:

Actually send emails (spam!).
Slow down by hitting a real database.
Depend on external services that might be unavailable.

Test doubles solve these problems by providing controlled, predictable replacements.

Dummy Objects: Just Placeholders

A Dummy Object is the simplest kind of test double. It's passed around but never actually used.

Think of it as a required parameter that your code doesn't care about in a specific test scenario. It just fills a slot.

Often null or an empty instance.
No behavior is expected from it.
Used when an argument is needed but irrelevant for the test.

Dummy Example: Irrelevant Data

Consider a UserService that needs an EmailSender but in a test scenario, we only care about user creation, not email sending.

Here, a null or a basic new EmailSender() might act as a dummy.

interface EmailSender {
  void sendEmail(String to, String subject, String body);
}

class UserService {
  private EmailSender emailSender;

  public UserService(EmailSender emailSender) {
    this.emailSender = emailSender;
  }

  public boolean createUser(String username) {
    // In this specific test, we don't care about emailSender
    // emailSender.sendEmail(username + "@example.com", "Welcome", "Hi!");
    return true; // Simplified for example
  }
}

public class Main {
  public static void main(String[] args) {
    // Here, null acts as a dummy object for createUser test
    EmailSender dummySender = null;
    UserService userService = new UserService(dummySender);
    boolean created = userService.createUser("testuser");
    System.out.println("User created: " + created);
  }
}

Stub Objects: Canned Responses

A Stub Object provides pre-programmed answers to method calls during a test. It doesn't perform any real logic; it just returns specific values.

Stubs are great when your test needs a dependency to return a particular piece of data to proceed.

Returns fixed, predetermined values.
Focuses on state-based testing.
Doesn't verify interactions, just supplies data.

Stub Example: Fixed Data

Let's say a ProductService needs a ProductRepository to find products. A stub can return a specific product without hitting a real database.

interface ProductRepository {
  String findProductNameById(int id);
}

class ProductRepositoryStub implements ProductRepository {
  @Override
  public String findProductNameById(int id) {
    if (id == 1) {
      return "Laptop";
    }
    return "Unknown Product";
  }
}

class ProductService {
  private ProductRepository repository;

  public ProductService(ProductRepository repository) {
    this.repository = repository;
  }

  public String getProductDetails(int productId) {
    return "Product: " + repository.findProductNameById(productId);
  }
}

public class Main {
  public static void main(String[] args) {
    ProductRepository stub = new ProductRepositoryStub();
    ProductService service = new ProductService(stub);
    System.out.println(service.getProductDetails(1));
    System.out.println(service.getProductDetails(2));
  }
}

Fake Objects: Light Implementations

A Fake Object has a working implementation, but it's simplified compared to the real one. It typically takes shortcuts that make it unsuitable for production but perfect for tests.

An in-memory database or a file system replacement are common examples of fakes.

Contains some logic, not just canned responses.
Simulates real behavior, but in a simpler way.
Useful for integration-like unit tests.

Fake Example: In-Memory DB

Here's a fake UserRepository that stores users in a simple HashMap instead of a real database. It simulates adding and finding users.

import java.util.HashMap;
import java.util.Map;

interface UserRepository {
  void addUser(String name);
  String findUser(String name);
}

class InMemoryUserRepository implements UserRepository {
  private Map<String, String> users = new HashMap<>();

  @Override
  public void addUser(String name) {
    users.put(name, name);
  }

  @Override
  public String findUser(String name) {
    return users.get(name);
  }
}

class UserService {
  private UserRepository repository;

  public UserService(UserRepository repository) {
    this.repository = repository;
  }

  public void registerUser(String username) {
    repository.addUser(username);
  }

  public boolean userExists(String username) {
    return repository.findUser(username) != null;
  }
}

public class Main {
  public static void main(String[] args) {
    UserRepository fakeRepo = new InMemoryUserRepository();
    UserService service = new UserService(fakeRepo);

    service.registerUser("Alice");
    System.out.println("Alice exists: " + service.userExists("Alice"));
    System.out.println("Bob exists: " + service.userExists("Bob"));
  }
}

Mock Objects: Behavior Verification

A Mock Object is a special type of stub that also records interactions. You use mocks to verify that a specific method was called on a dependency, with specific arguments, and a certain number of times.

Mocks are central to behavior-driven testing, where you care about how your object interacts with its collaborators.

Records method calls and arguments.
Allows verification of interactions.
Often created by mocking frameworks (like Mockito!).

Mocks vs. Stubs: Behavior or State?

The main difference lies in their purpose:

Stubs: Focus on state verification. They provide data needed for the test to run, and the test asserts on the state of the system under test.
Mocks: Focus on behavior verification. They verify that the system under test interacted with its dependencies in a specific way.

You often combine them: a stub provides data, and a mock verifies an action.

Test Double Check

Which type of test double is primarily used to verify that a specific method was called on a dependency?

Recap: The Test Double Family

We've explored the different types of test doubles and why they're essential for writing good tests:

Dummy: A placeholder, passed but not used.
Stub: Provides canned answers to method calls.
Fake: A simplified working implementation.
Mock: Verifies interactions and behavior.

Understanding these helps you choose the right tool for isolating and testing your code effectively. Next, we'll dive into how Mockito helps us create these mocks!

Questions Fréquemment Posées

La leçon « Objets simulés, bouchons et doublures » est-elle gratuite ?

Oui — le texte complet de « Objets simulés, bouchons et doublures » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Testing Mastery: JUnit, Mockito & Integration Tests, passe à CoddyKit PRO. Le cours Testing Mastery: JUnit, Mockito & Integration Tests comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Objets simulés, bouchons et doublures » ?

Distinguez les différents doubles de test : objets simulés, bouchons, doublures et objets factices, et comprenez leur rôle dans les tests. Tu pratiques Testing Mastery: JUnit, Mockito & Integration Tests avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Testing Mastery: JUnit, Mockito & Integration Tests ?

Aucune expérience préalable n'est requise. Testing Mastery: JUnit, Mockito & Integration Tests sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Objets simulés, bouchons et doublures » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Testing Mastery: JUnit, Mockito & Integration Tests ?

Oui. Chaque leçon Testing Mastery: JUnit, Mockito & Integration Tests inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Objets simulés, bouchons et doublures
Créer des objets simulés avec Mockito
Vérifier les interactions avec les objets simulés
Injecter des simulations avec @Mock et @InjectMocks

← Retour à Testing Mastery: JUnit, Mockito & Integration Tests