Test-Driven Development : les tests au coeur du développement

Avec ce MON, je compte étudier la méthodologie Test-Driven Development qui repose sur l'écriture de test en amont (généralement les tests sont implémentés après le code). Ainsi, je vais me former à l'écriture de tests. Enfin, j'aimerais me familiariser avec un outil de gestion de tests (Jenkins par exemple) et comprendre comment l'intelligence artificielle (Copilot, GPT) peut être un outil privilégié dans l'écriture de tests. Exceptionnellement, ce MON sera constitué de 15 heures de travail.

Table des matières

• Table des matières
• 1. Test-Driven Development : Comprendre la méthodologie
• 2. Exemple (perturbant) de mise en application
• 3. Les principaux tests rencontrés en informatique
• 4. Framework de test pour Javascript
• 5. Mise en pratique du tdd : morpion (Angular + Jasmine)
• 6. Utiliser GitHub Copilot pour implémenter ses tests
  • Ma question
  • La réponse de GitHub Copilot Chat
  • Analyse de sa réponse
• Sources utiles

1. Test-Driven Development : Comprendre la méthodologie

La méthodologie Test-Driven Development (tdd) consiste à concevoir un logiciel par des itérations successives courtes, telles que chacune de ses itérations correspond à un problème à résoudre formulé sous forme de test.

Le tdd suit généralement un cycle en trois étapes :

1. Red : Ecrire un test qui échoue (car le code pour le satisfaire n'existe pas encore, puisqu'on écrit le test en amont du code).
2. Green : Ecrire le minimum de code nécessaire pour que le test réussisse. On ne s'occupe pas ici de l'algorithme utilisé ou de sa performance.
3. Refactor : Améliorer le code tout en gardant les tests au "vert", de sorte à ce que sa performance soit optimale.

import unittest

class TestAddition(unittest.TestCase):
    def test_add_two_numbers(self):
        self.assertEqual(add(4, 3), 7)  # étant donné qu'on écrit le test en amont, la fonction add n'a pas encore été codée

def add(a,b):
  return a + b

Les erreurs récurrentes à ne pas faire en tdd :

• Oublier d'exécuter régulièrement les tests
• Ecrire trop de tests à la fois, ou des tests trop complexes. Il est important d'avancer par petits pas.
• Ecrire des tests qui manquent d'assertions, c'est-à-dire des tests qui ne vérifient pas correctement que le code fonctionne comme souhaité. Exemple d'assertion en Python avec unittest : self.assertEqual(add(2, 3), 5)

Les (nombreux) avantages du tdd :

• Amélioration de la qualité du code : code robuste, bien structuré et moins sujet aux bugs.
• Réduction des bugs et régressions : suite de tests automatisée qui garantit que chaque modification du code est validée. Cela aide à prévenir les régressions lorsque de nouvelles fonctionnalités ou des corrections de bugs sont introduites.
• Conception guidée par les tests : cela évite le surdéveloppement ou l'écriture de code inutile, ce qui améliore la clarté et la maintenabilité.
• Conception axée sur les résultats : on se concentre sur les objectifs fonctionnels (ce que le code doit faire) au lieu de se perdre dans les détails de l'implémentation.
• Documentation vivante : les tests eux-mêmes servent de documentation technique vivante qui décrit comment chaque fonctionnalité est censée fonctionner.
• Méthodologie adapté à l'intégration continue : le tdd garantit un flux de développement fluide, avec des livraisons fréquentes et fiables. On avance continuement petit pas par petit pas

2. Exemple (perturbant) de mise en application

J'ai lu un exemple bien détaillé ("The Money Example" écrit en java) respectant à la lettre la méthodologie du tdd dans le livre Tesr-Driven Development by example écrit par Kent Beck (disponible au centre de documentation). C'est assez perturbant lorsqu'on n'est pas familier avec le tdd ! Par exemple, pour son premier test :

  public void testMultiplication(){
    Dollar five = new Dollar(5);
    five.times(2);
    assertEquals(10, five.amount)
  }

Kent Beck va au plus simple (comme le veut le tdd) et implémente cette classe Dollar :

  class Dollar

  Dollar(int amount){ //constructeur qui ne fait rien
  }
  void times(int multiplier){ //méthode times utilisée dans le test, mais qui ne fait/renvoie rien
  }
  int amount = 10; //Pour passer le test

On voit ici qu'il n'a pas du tout écrit un code qui permet de multiplier deux nomnres... Il a simplement cherché à réussir le premier test de la manière la plus simple possible !

En plus, de toutes les règles explicitées dans la partie 1, Kent Beck souligne l'importance d'éviter la duplication entre test et code lors de la phase refactor de chaque cycle du tdd. C'est ainsi qu'il va revoir le code précédement écrit pour son premier test et l'améliorer (car il y a une répétition du nombre 10 qu'on trouve à la fois dans testMultiplication et dans int amount = 10).

De plus il montre que le principe de triangularisation dans les tests est important. Ce principe veut qu'on parte de tests simples et larges, dans un premier temps. Puis, au fur et à mesure, qu'on les affine pour se concentrer sur les détails en garantissant que l'ensemble des scénarios sont couverts par des tests.

3. Les principaux tests rencontrés en informatique

Test unitaire : petite portion de code écrite pour vérifier qu'une partie spécifique de l'application fonctionne comme prévu. Cela aide à identifier rapidement des erreurs ou régressions (bugs ou comportements incorrects introduits dans une fonctionnalité qui fonctionnait correctement auparavant).

Test d'intégration : il vérifie que plusieurs composants ou modules d'une application fonctionnent correctement ensemble.

Test end-to-end (E2E) : il simule l'interaction complète d'un utilisateur avec l'application dans un environnement réel ou presque réel. Il permet de tester l'application dans son ensemble, en vérifiant que toutes les parties du système fonctionnent correctement ensemble, y compris l'interface utilisateur, les services backend, les bases de données, etc

4. Framework de test pour Javascript

En faisant quelques recherches, j'ai réalisé qu'il y avait de nombreux outils utilisés pour faciliter l'écriture, l'exécution et l'organisation des tests. Parmi ces outils :

• Jest : un framework de tests complet et très populaire développé par Facebook. Ce framework permet d'implémenter des tests unitaires, d'intégration et E2E. Il peut être utilisé pour une multitude de projets dont des projets TypeScript, Node, React, Angular, Vue, ...
• Jasmine : framework de test complet et populaire. Il offre une syntaxe claire et simple qui se prète bien à l'écriture de tests unitaires et d'intégration. Angular utilise Jasmine comme framework de tests par défaut. On l'utilise souvent en duo avec Karma (outil d'exécution des tests qui s'assure que ces tests sont exécutés dans des navigateurs et fournit des rapports sur leur réussite ou échec).

Pour la suite, nous allons utiliser Jasmine, dans un environnement Angular.

5. Mise en pratique du tdd : morpion (Angular + Jasmine)

describe("Addition", function() {
  it("should add two numbers correctly", function() {
    const result = 2 + 3;
    expect(result).toBe(5);  // Vérification de la valeur obtenue
  });
});

describe('Authentification', function() {
  let authService;

  beforeEach(function() {
    authService = new AuthService();  // Initialisation du service d'authentification
  });

  it('should log in successfully with valid credentials', function() {
    const result = authService.login('user@example.com', 'password123');
    expect(result).toBe(true);
  });

  it('should fail login with invalid credentials', function() {
    const result = authService.login('user@example.com', 'wrongpassword');
    expect(result).toBe(false);
  });

  it('should return user info on successful login', function() {
    const result = authService.login('user@example.com', 'password123');
    expect(result.user).toEqual({ email: 'user@example.com' });
  });
});

import { TestBed } from '@angular/core/testing';
import { AppComponent } from './app.component';

describe('AppComponent', () => {
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [AppComponent],
    }).compileComponents();
  });

  it('should create the app', () => {
    const fixture = TestBed.createComponent(AppComponent);
    const app = fixture.componentInstance;
    expect(app).toBeTruthy();
  });

  it(`should have the 'morpion' title`, () => {
    const fixture = TestBed.createComponent(AppComponent);
    const app = fixture.componentInstance;
    expect(app.title).toEqual('morpion');
  });

  it('should render title', () => {
    const fixture = TestBed.createComponent(AppComponent);
    fixture.detectChanges();
    const compiled = fixture.nativeElement as HTMLElement;
    expect(compiled.querySelector('h1')?.textContent).toContain('Hello, morpion');
  });
});

describe('CaseComponent', () => {
  let component: CaseComponent;
  let fixture: ComponentFixture;

  // ...

  it('should render a box',() => {
    const boxElement = fixture.nativeElement.querySelector('.case');
    expect(boxElement).toBeTruthy(); //vérifie qu'un élément avec la class .case est présent
  });
});

<button class="case">
</button>

describe('CaseComponent', () => {
  let component: CaseComponent;
  let fixture: ComponentFixture;

  // ...

  it('should trigger a click event',() => {
    spyOn(component,'onClick'); //espion de la méthode onClick (créer d'abord la méthode dans case.component.ts)
    const boxElement = fixture.nativeElement.querySelector('.case');
    boxElement.click(); //Simule le click
    expect(component.onClick).toHaveBeenCalled(); //Vérifie que la méthode `onClick` a été appelée
  });
});

<button class="case" (click)="onClick()">
</button>

describe('CaseComponent', () => {
  let component: CaseComponent;
  let fixture: ComponentFixture;

  // ...

  it('should accept only values : X or O or empty',()=>{
    component.value = 'X'; //on assigne une valeur valide
    expect(component.value).toBe('X'); // Vérifie que la valeur est bien "X"

    component.value = 'O';
    expect(component.value).toBe('O');

    component.value = null;
    expect(component.value).toBe(null);

    component.value = 'valeur invalide' as any; // Cas pour tester une valeur invalide
    expect(component.value).not.toBe('Valeur invalide');  // Vérifie que la valeur invalide n'a pas été acceptée
  });
});

export class CaseComponent {
  onClick(){
  };

  private _value: string | null = null; // Stockage interne de la valeur

  get value(): string | null {
    return this._value;
  }

  set value(val: string | null) {
    if (val === 'X' || val === 'O' || val === null) {
      this._value = val;
    } else {
      console.warn('Valeur invalide : ', val);
    }
  }

}

describe('CaseComponent', () => {
  let component: CaseComponent;
  let fixture: ComponentFixture;

  // ...

  it('should change value when clicked (null --> X or null --> O)',()=>{
    const boxElement = fixture.nativeElement.querySelector('.case');

    component.value = null; //si on clique sur une case vide, on change sa valeur
    boxElement.click();
    expect(component.value).not.toBeNull();

    component.value = 'X'; //si on clique sur une case avec une croix, sa valeur doit rester la même
    boxElement.click();
    expect(component.value).toBe('X');

    component.value = 'O'; //si on clique sur une case avec un cercle, sa valeur doit rester la même
    boxElement.click();
    expect(component.value).toBe('O');
  });
});

onClick(){
    if(this.value === null){
      this._value = 'X';
    }
  };

describe('CaseComponent', () => {
  let component: CaseComponent;
  let fixture: ComponentFixture;

  // ...

  it('should display the correct value inside the box',()=>{
    const boxElement = fixture.nativeElement.querySelector('.case');

    component.value = 'X';
    fixture.detectChanges(); //pour que le html affiche bien la nouvelle valeur !
    expect(boxElement.textContent.trim()).toBe('X');

    component.value = 'O';
    fixture.detectChanges();
    expect(boxElement.textContent.trim()).toBe('O');

    component.value = null;
    fixture.detectChanges();
    expect(boxElement.textContent.trim()).toBe('');
  });
});

describe('GrilleComponent', () => {
  let component: GrilleComponent;
  let fixture: ComponentFixture;

  // ...

  it('should render 9 boxes',()=>{
    const boxElements = fixture.debugElement.queryAll(By.css('.app-case')); //sélectionne tous les éléments app-case
    expect(boxElements.length).toBe(9); //on vérifie qu'il y en a bien neuf
  })
});

import { Component } from '@angular/core';
import { CaseComponent } from '../case/case.component';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-grille',
  standalone: true,
  imports: [CommonModule, CaseComponent],
  templateUrl: './grille.component.html',
  styleUrl: './grille.component.css'
})
export class GrilleComponent {
  cases = Array(9).fill(null); // Tableau pour générer 9 cases
}

<div class="grille">
    <app-case *ngFor="let case of cases"></app-case>
</div>

6. Utiliser GitHub Copilot pour implémenter ses tests

suite à venir (en cours de rédaction)

Pour ceux qui ne connaissent pas cet outil, GitHub Copilot c'est une IA, plus précisément un LMM (comme chatGPT), utilisé pour le développement informatique. Son plus grand atout : un gain d'efficacité remarquable.

Cet outil est payant, mais il y a une offre étudiante (GitHub Copilot Student) qui est gratuite. C'est celle-ci, que j'utilise.

GitHub Copilot peut être ajouté, en tant qu'extension, à son IDE (par exemple à Visual Studio Code). Quand tu installes Copilot sur VS Code, deux extensions sont ajoutées :

• GitHub Copilot, qui propose de compléter le code de façon "intelligente" (auto-completion).
• GitHub Copilot Chat, qui permet d'avoir une conversation avec l'IA via une interface conversationnelle, similaire à ChatGPT.

GitHub Copilot, une fois intégré à VS Code est un outil très puissant puisqu'il peut scanner le code déjà écrit et proposer des améliorations sur le code existant, ou des suggestions pour continuer le développement.

// ...existing code...

// Method to check for a win
checkWin(): boolean {
  const winPatterns = [
    [0, 1, 2], [3, 4, 5], [6, 7, 8], // Rows
    [0, 3, 6], [1, 4, 7], [2, 5, 8], // Columns
    [0, 4, 8], [2, 4, 6]             // Diagonals
  ];

  return winPatterns.some(pattern =>
    pattern.every(index => this.board[index] === this.currentPlayer)
  );
}

// Method to check for a draw
checkDraw(): boolean {
  return this.board.every(cell => cell !== null);
}

// Method to handle the end of the game
handleEndGame() {
  if (this.checkWin()) {
    console.log(`Player ${this.currentPlayer} wins!`);
    // Additional logic to handle win (e.g., disable further moves)
  } else if (this.checkDraw()) {
    console.log("It's a draw!");
    // Additional logic to handle draw
  } else {
    this.changePlayer(this.currentPlayer);
  }
}

// Modify the onClick method to include end game check
onClick(index: number) {
  if (!this.board[index]) {
    this.board[index] = this.currentPlayer;
    this.handleEndGame();
  }
}

// ...existing code...

GitHub Copilot est excellent pour l'auto-completion, il m'a devancé à de nombreuses reprises. Il m'a été d'une grande utilité pour implémenter le design du jeu, en me proposant des feuilles CSS toutes faites ! Quel grand gain de temps.

Je sais dorénavant que j'utiliserai GitHub Copilot sur d'autres projets !

Sources utiles