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

Écrire les tests en premier

Entraînez-vous à écrire des tests qui échouent et définissent le comportement attendu avant d'implémenter le moindre code de production.

Écrire les tests en premier est une leçon Testing Mastery: JUnit, Mockito & Integration Tests gratuite sur CoddyKit. Ceci est la leçon 2 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.

TDD's 'Red' Phase

Welcome to the core of Test-Driven Development (TDD)! In this lesson, we'll dive into the crucial first step: writing a failing test first.

This is often called the 'Red' phase of the TDD cycle, because when you run your tests, you expect to see a 'red bar' indicating a failure.

Why Test First?

It might feel counter-intuitive to write a test for code that doesn't exist yet, or isn't fully implemented. But this approach offers great benefits:

Clarity: It forces you to think about what the code should *do* before you think about *how* to do it.
Proof of Failure: It proves your test works correctly by showing it can fail. If it passes without any code, your test might be faulty!
Focus: It gives you a clear, immediate goal: make this one test pass.

Tests as Specifications

Think of your failing test as a precise specification or a mini-requirement. It describes a specific behavior your future code must exhibit.

It defines the input.
It defines the expected output or outcome.
It's concrete and executable.

This helps prevent misunderstandings and ensures your code delivers exactly what's needed for that specific scenario.

Scenario: Simple Calculator

Let's practice by building a simple Calculator class. For our first piece of functionality, we want it to be able to add two numbers.

Our goal is to write a test for an add method that will fail before we even write the correct implementation of add.

Designing the Failing Test

Before writing code, let's think:

What input? We'll add 2 and 3.
What output? We expect the result to be 5.
What method? A method called add on a Calculator object.

We'll write a test that calls calculator.add(2, 3) and asserts that the result is 5.

Code Demo: The Failing Test

Here's a simulated example of writing a test first. Notice the Calculator's add method is intentionally incorrect (it returns 0). This makes our 'test' fail, demonstrating the 'Red' phase.

Run this code to see the simulated failure!

public class Main {
    public static void main(String[] args) {
        System.out.println("Running a simulated test...");
        Calculator calculator = new Calculator();

        // Our test scenario: 2 + 3 should be 5
        int expected = 5;
        int actual = calculator.add(2, 3);

        if (expected == actual) {
            System.out.println("Test PASSED: 2 + 3 = " + actual);
        } else {
            System.out.println("Test FAILED: Expected " + expected + " but got " + actual);
            System.out.println("This is our 'Red' phase!");
        }
    }
}

// The production code (intentionally incorrect for 'Red' phase)
class Calculator {
    public int add(int a, int b) {
        return 0; // Wrong implementation to make the test fail
    }
}

Analyzing the 'Red'

After running the previous code, you saw a 'Test FAILED' message. This is exactly what we wanted!

Expected: 5
Actual: 0

This failure confirms two things: our test is correctly written, and the production code (the add method) does not yet meet the specified behavior.

The 'Minimum Code' Mindset

Once you have a failing test, the next step in TDD (the 'Green' phase) is to write the *simplest possible code* to make that test pass.

Don't over-engineer.
Don't add extra features.
Just focus on satisfying the current failing test.

This keeps your code clean and focused, building functionality incrementally.

Advantages of Test-First

Embracing the 'Red' phase of TDD leads to:

Better Design: Tests guide you towards more modular and testable code.
Increased Confidence: Each passing test gives you confidence in your code's correctness.
Reduced Bugs: Catch issues early, before they become complex problems.
Living Documentation: Your tests serve as up-to-date examples of how your code should be used.

Quick Check on TDD Red

Let's test your understanding of the 'Red' phase in Test-Driven Development.

Recap: The 'Red' Phase

You've explored the crucial first step of TDD: writing a failing test.

The 'Red' phase means writing a test that fails.
This test acts as a clear specification for new functionality.
Seeing the test fail confirms its validity and that the code isn't yet correct.
This methodical approach leads to clearer requirements and more robust code.

Next, we'll learn how to make that failing test pass – the 'Green' phase!

Questions Fréquemment Posées

La leçon « Écrire les tests en premier » est-elle gratuite ?

Oui — le texte complet de « Écrire les tests en premier » 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 « Écrire les tests en premier » ?

Entraînez-vous à écrire des tests qui échouent et définissent le comportement attendu avant d'implémenter le moindre code de production. 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 2 sur 4.

Combien de temps prend la leçon « Écrire les tests en premier » ?

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

Introduction au cycle TDD
Écrire les tests en premier
Refactoriser pour améliorer la testabilité
Les trois lois du TDD

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