You'll find clear explanations about Test-Driven Development, Code Reviews, Technical Debt, the Tech Lead role, and how to apply these concepts within your company.

It’s beginner-friendly, easy to read, and super useful. Enjoy!

Language:
English

How to get it?
Just fill out the form with a valid email address, and you’ll receive the download link straight to your inbox.

https://publication.octo.com/en/download-whitepaper-culture-code

Description [FR]:
Culture Code, c’est un livre blanc publié par Octo Technology. Il est dispo gratuitement et te donne plein de conseils concrets pour te familiariser avec le Software Craftsmanship.

Tu y trouveras des explications claires sur le TDD, les Code Reviews, la Dette Technique, le rôle de Tech Lead, et comment appliquer tout ça dans ta boîte.

C’est super accessible, facile à lire, et franchement utile. Bonne lecture!

Langue :
Français

Comment l’obtenir ?
Il te suffit de remplir le formulaire avec une adresse mail valide, et tu recevras directement le lien de téléchargement dans ta boîte mail.

👉 https://publication.octo.com/fr/telechargement-livre-blanc-culture-code

Mais y’a des petits trucs simples à retenir qui peuvent t'aider. Ça va pas régler tous tes soucis, certes, mais ça peut clairement te débloquer quand tu ne sais pas trop par où commencer.

Parce qu’au fond, si tu prends deux secondes pour y penser, à part quelques cas très particuliers (tests de perf, de sécu, etc.), y’a que trois manières de vérifier qu’un bout de code fait ce que tu attends de lui.

Pas dix, pas cinquante. Juste trois.

Et une fois que tu as compris ça, tout devient beaucoup plus simple.

La seule question à te poser

Commence juste par répondre à cette simple question:

Est-ce que le résultat que je veux vérifier est direct, indirect ou une collaboration?

Bon là je vois déjà ta tête:

“Oula c’est quoi ces trucs, je comprends rien, laisse tomber…”.

→ T’inquiètes pas on va voir ça ensemble avec des exemples.

Direct output

On commence avec le plus simple. Et ça tombe bien parce que c’est celui que tu vas essayer d’utiliser le plus souvent. C’est aussi celui qui va te paraitre le plus naturel.

Imagine que le code que tu essaie d’écrire est celui d'une “machine”. On ne sait pas ce qu’il y a à l’intérieur.

Cette machine, tu lui as donné un but. Ici son but est de “créer une potion à partir d’une herbe”.

→ Donc ce que la machine va “recevoir en entrée”, ce sont des herbes.

→ Ce qu’elle “renverra en sortie” c’est une potion.

Si tu traduis ça en test, vu qu’on est en train de faire du TDD, tu pourrais imaginer quelque chose comme ça (avec des strings pour rester simple):

it('should create a green potion from green herb', () => {
    // Arrange
    const machine = new Machine();
    const herb = 'green-herb';

    // Act
    const potion = machine.createPotion(herb);

    // Assert
    expect(potion).toBe('green-potion');
});

Tu vois, on retranscrit assez facilement ce qu’on a dit juste au-dessus. On passe une herb en entrée, et en retour on reçoit une potion verte. Le résultat est direct.

C’est le cas le plus simple à tester car tu vas pouvoir passer des valeurs différentes en entrée et checker le résultat en sortie assez facilement.

C’est souvent le cas des calculs d'ailleurs.

Quand on calcule la somme de deux nombres, c’est assez naturel de se dire “si je passe 1 et 2 en entrée, le result doit être égal à 3”.

it('should make the sum of two numbers', () => {
    // Arrange
    const a = 1;
    const b = 2;

    // Act
    const result = sum(a, b);

    // Assert
    expect(result).toBe(3);
});

Bref, le truc c’est de se dire que, si le code que tu souhaites tester renvoie quelque chose, c’est du “direct output” et c'est facilement testable.

Indirect output

Parfois ça peut être un peu plus compliqué. Le résultat peut être disponible mais “ailleurs”. Et donc pour écrire ton test, tu vas devoir prendre en compte cette contrainte toi aussi. Reprenons notre exemple avec une petite subtilité.

Notre machine est reliée à une lampe qui devient verte quand la potion a bien été créée.

Dans notre cas, la lampe est externe à la machine. La machine y accède d’une façon ou d’une autre, et déclenche un changement d’état.

Comment elle fait? On s’en fiche, tout ce qu’on sait c’est que la machine ne “renvoie pas” une lampe en sortie… C’est donc un “indirect output”.

Si tu traduits ça en test, une solution possible serait:

it('should change the color of the lamp to green', () => {
    // Arrange
    const lamp = new Lamp();
    const machine = new Machine(lamp);
    const herb = 'green';

    // Act
    machine.createPotion(herb);

    // Assert
    expect(lamp.color).toBe('green');
});

On lit facilement que la machine a accès à la lamp, et qu’après avoir créé la potion, la lamp devient verte.

Mais contrairement à la version direct output, ça demande une petite gymnastique mentale en plus.

Et voilà pour notre deuxième façon de tester.
Encore une dernière, et on a fait le tour.

Collaborateurs

Suivant les tests que tu souhaites faire, parfois tu vas vouloir vérifier que les choses se déroulent exactement comme tu le souhaites.

Ce ne sera pas un résultat qui sera checké, mais un comportement.
On va vouloir vérifier que les acteurs (qu’on va appeler collaborateurs) remplissent bien leur rôle comme il faut. Voici un exemple.

La lampe doit clignotter 3 fois pour avertir qu’une nouvelle potion est prête.

Plusieurs choses ici.

Allumer/éteindre une lampe, c’est peut-être long. Ça consomme de l’énergie, ça use l’ampoule.
Bref, c’est pas un truc qu’on veut faire pour de vrai en test.
Le mieux serait d’utiliser un “test double” ou “doublure de test” en francais pour éviter ces problèmes.

Ce qu’on veut ici, c’est s’assurer que la méthode blink() a bien été appelée 3 fois.

it('should make the lamp blink 3 times', () => {
    // Arrange
    const lamp = new Lamp();
    spyOn(lamp, 'blink').mockImplementation();    
    const machine = new Machine(lamp);
    const herb = 'green';

    // Act
    machine.createPotion(herb);

    // Assert
    expect(lamp.blink).toBeCalledTimes(3);
});

✋ Hophophop! T’as plein de manières de faire des doublures de tests.
Ici je retranscrits uniquement ce que nous avons dit au dessus.
J’ai utilisé le spyOn avec mockImplementation (dispo dans jest & vitest) dans cet exemple car je pense que tu as déjà dû les rencontrer dans la doc ou des tutos.
Mais ce n’est clairement pas la seule facon de faire.
On verra notamment comment créer nos propres doublures sans librairie et les différences entre chaque type de doublure (dummy, stubs, spy, fakes etc…). Mais en attendant, on va rester sur cette proposition.

Ici, tu ne vérifies pas un état mais plutôt que ton collaborateur a bien été sollicité comme prévu pour remplir son job.
→ Tu valides donc un comportement.

Ce que tu dois retenir

Quand tu veux écrire un test, demande toi si tu veux vérifier:

• Ce que le code produit (direct)

• Ce qu'il change ailleurs (indirect)

• Ce qu'il fait faire aux autres (collaboration)

Pour aller plus loin

Bien entendu les termes ici ont été simplifiés. Mais ça devrait t'aider à y voir plus clair pour écrire tes prochains tests.

Si tu souhaites pousser plus loin, tu peux retrouver tout ça sous les noms:

• Direct → State Verification

• Indirect → Observable Side Effect, Indirect Output

• Collaboration → Interaction Testing, Behavior Verification

→ Mais t’inquiètes pas, on verra tout ça un peu plus dans les prochains articles.

Voilà quelques livres incontournables sur le TDD (liens d’affiliation Amazon):

• xUnit Patterns (Gerard Meszaros): https://amzn.to/42pw3hZ - Assez vieux mais l’un des meilleur concernant les patterns de tests

• TDD by Example (Kent Beck): https://amzn.to/3YvZu0G

Dans un prochain article, on parlera des inputs directs et indirects donc reste à l'écoute.

But there are a few simple ideas that can really help.
They won’t magically fix everything, but they’ll definitely help you get unstuck when you don’t know where to begin.

Because if you take two seconds to really think about it, aside from edge cases like perf or security testing, there are only three ways to check that a piece of code is doing what you expect.

Not ten. Not fifty. Just three.

Once you get that, everything starts to make a lot more sense.

The only question you need to ask

Start by asking yourself this one simple question:

Is the result I want to verify direct, indirect, or part of a collaboration?

I can already see your face:

“Uhhh what? I have no idea what that means. Nevermind…”

→ Don’t worry. Let’s walk through it together with examples.

1. Direct output

Let’s start with the simplest one, and the one you’ll try to use most often.
It also happens to feel the most natural.

Imagine the code you're writing is a "machine".
You don't really care what’s going on inside.

That machine has one purpose.
In our case: “create a potion from a herb”.

→ So the machine takes an herb as input...

→ ...and gives you a potion as output.

If we translate this into a TDD-style test, you might write something like:

it('should create a green potion from green herb', () => {
  // Arrange
  const machine = new Machine();
  const herb = 'green-herb';

  // Act
  const potion = machine.createPotion(herb);

  // Assert
  expect(potion).toBe('green-potion');
});

Pretty straightforward, right?

You feed a herb into the machine, and the return value is a green potion.

→ That’s a direct result.

Direct results are the easiest to test: you pass something in, you get something out, you check the output.

It’s the same with a simple calculation. Let’s say you're writing a sum() function:

it('should make the sum of two numbers', () => {
  // Arrange
  const a = 1;
  const b = 2;

  // Act
  const result = sum(a, b);

  // Assert
  expect(result).toBe(3);
});

In short: if your code returns a value, it’s direct, and that’s the easiest kind of thing to test.

2. Indirect output

Sometimes things are a bit trickier.
The result exists, but it’s visible somewhere else, and your test needs to account for that.

Let’s tweak our potion machine example just a bit.

Our machine is connected to a lamp that turns green when the potion is ready.

In this case, the lamp is external to the machine.
The machine can somehow access it and update its state.

How? Who cares? What matters is that the machine doesn’t return the lamp.
→ So this is an indirect result.

Here’s how that might look in a test:

it('should change the color of the lamp to green', () => {
  // Arrange
  const lamp = new Lamp();
  const machine = new Machine(lamp);
  const herb = 'green';

  // Act
  machine.createPotion(herb);

  // Assert
  expect(lamp.color).toBe('green');
});

You can clearly see from the test that the machine has access to the lamp, and after creating a potion, the lamp turns green.

It’s still readable and testable, but it’s a little more work than the direct case.

And that’s your second way of verifying results. One more to go.

3. Collaboration

In some tests, what you want to verify isn’t a result or a state.
It’s a behavior, something that happened.

You want to check whether the right thing was done by a collaborator.

Let’s go back to our potion machine:

The lamp should blink 3 times to signal that a potion is ready.

Now blinking the lamp could take time. It could drain power. Maybe those lightbulbs are expensive.

→ In tests, we want speed, low cost, and predictability.

So the better move is to use a test double: a fake object that helps us verify what happened.

We want to verify that our collaborator lamp had its blink method called exactly 3 times.

it('should make the lamp blink 3 times', () => {
  // Arrange
  const lamp = new Lamp();
  spyOn(lamp, 'blink').mockImplementation();    
  const machine = new Machine(lamp);
  const herb = 'green';

  // Act
  machine.createPotion(herb);

  // Assert
  expect(lamp.blink).toBeCalledTimes(3);
});

✋ Heads up! There are lots of ways to create test doubles.
Here I’m just sticking with what we’ve already discussed.
I used spyOn with mockImplementation (from Jest or Vitest) because you’ve probably seen that before in docs or tutorials.
But it’s not the only way!
In a future post, I’ll show how to create your own test doubles without any library, and break down the differences between dummies, stubs, spies, fakes, and mocks.

So here, you’re not checking a return value or a state.
You’re checking that another element was used correctly.
→ That’s what we call verifying a collaboration.

TLDR:

Whenever you’re about to write a test, just ask:

• What does the code produce? → Direct

• What does it change somewhere else? → Indirect

• What does it ask another object to do? → Collaboration

Want to go deeper?

Obviously, the names I use here are simplified, but this structure will help a ton when you're getting into TDD.

If you want to read more, here are the “official” names for these techniques:

• Direct → State Verification

• Indirect → Observable Side Effect, Indirect Output

• Collaboration → Interaction Testing, Behavior Verification

Some books if you want to dig in deeper (Amazon affiliate links):

• xUnit Patterns (Gerard Meszaros): https://amzn.to/42pw3hZ - Old one but great for testing patterns

• TDD by Example (Kent Beck): https://amzn.to/3YvZu0G

In an other article, we will discuss about direct and indirect inputs, stay tuned!

Language:
English

How to get it?
Just fill out the form on the website with a valid email address, and you'll receive the download link directly in your inbox.

👉 Ultimate Courses - JavaScript Array Methods

Description [FR]:
Avec ce PDF de très grande qualité (et gratuit!), Todd Motto t’aide à comprendre les méthodes avancées des tableaux en JavaScript. Tu verras aussi bien les bases (forEach, map, filter) que des méthodes plus poussées comme reduce, find, some ou every. Garde-le de côté, ça te servira toujours!

Langue:
Anglais

Comment l’obtenir?
Il te suffit de remplir le formulaire sur le site en indiquant une adresse mail valide et tu recevras le lien de téléchargement directement dans ta boîte mail.

👉 Ultimate Courses - JavaScript Array Methods