Angular - Front-End Framework (2/2)

• [x] Implémenter les parties manquantes du site :
  • [x] Implémenter la partie Mes recettes
  • [x] Implémenter la fonctionnalité permettant de mettre une recette en favoris
  • [x] Implémenter le header pour une navigation fluide et cohérente
• [x] Tester le site :
  • [x] Revoir les tests automatiquement générés par Angular
  • [x] Ajouter des tests unitaires pour valider les différentes fonctionnalités
  • [x] Créer un jeu de données de test
  • [x] Tests pour voir si l'affichage est correct (pour la page d'accueil, pour les listes de recettes et pour les points d'information)
  • [x] Tester les endpoints (GET une recette)
  • [x] Tester les filtres
    • [x] Tester le filtre propriétaire de la recette
    • [x] Tester le filtre type de recette
    • [x] Tester le filtre barre de recherche
    • [x] Tester plusieurs filtres en même temps

Temps total passé sur ce sprint : 11H00

• [x] Implémenter les parties manquantes du site :
  • [x] Implémenter une fonctionnalité permettant de gérer les utilisateurs
  • [x] Implémenter une fonctionnalité permettant à chaque utilisateur d'avoir sa propre liste de recettes favorites
  • [x] Implémenter la fonctionnalité permettant d'ajouter une recette
  • [x] Implémenter la fonctionnalité permettant de supprimer une recette
• [x] Tester le site :
  • [x] Tester ajout d'une recette
  • [x] Tester suppression d'une recette
• [x] Déployer le site sur aioli

Temps total passé sur ce sprint : 10H10

Après avoir réalisé mon MON 3.1 sur la méthodologie Test-Driven Development, j'ai été content et satisfait de voir que les connaissances acquises peuvent être facilement réutilisées. Il faut que je veille à bien documenter mon code (les tests peuvent là aussi servir), car après quelques semaines, il est difficile de se familiariser de nouveau avec du code existant.

J'ai également vu la limite de la maquette Figma (cf POK 2). Celle-ci est très pratique pour avoir une idée du rendu final. Cependant, elle ne tient pas compte de la faisabilité des fonctionnalités souhaitées. Pour illustrer cela, je peux parler du header, qui change constamment dans ma maquette (certains icônes apparaissent seulement sur des pages spécifiques). Ce header, bien que pratique sur la maquette, est affreusement compliqué, long et énervant à coder !

Création d'un service Angular (UserService)

Lorsque on "mock" un service en Angular, on simule son comportement à l'aide d'un objet espion (spy). Cela signifie qu'on remplace le service réel par un faux service qui a des méthodes contrôlées. Ces méthodes ne réalisent aucune logique réelle, mais elles retournent des résultats simulés pour le test.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class UserService {
  getUser() {
    return { name: 'Titouan', age: 25 };
  }
}

Création du composant utilisant ce service (UserComponent)

import { Component } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-user',
  template: `<p> {{ user?.name }} ({{ user?.age }} ans)</p>`,
})
export class UserComponent {
  user: any;

  constructor(private userService: UserService) {}

  ngOnInit() {
    this.user = this.userService.getUser();
  }
}

Écriture du test unitaire avec un mock du service

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { UserComponent } from './user.component';
import { UserService } from './user.service';
import { of } from 'rxjs'; // Permet de créer des valeurs observables simulées

describe('UserComponent', () => {
  let component: UserComponent;
  let fixture: ComponentFixture<UserComponent>;
  let mockUserService: jasmine.SpyObj<UserService>;

  beforeEach(() => {
    // Création d’un mock du UserService
    mockUserService = jasmine.createSpyObj('UserService', ['getUser']);

    // Simulation d'une réponse du service
    mockUserService.getUser.and.returnValue({ name: 'Mocked User', age: 99 });

    TestBed.configureTestingModule({
      declarations: [UserComponent],
      providers: [{ provide: UserService, useValue: mockUserService }], // On remplace le vrai service par le mock
    }).compileComponents();

    fixture = TestBed.createComponent(UserComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should display mocked user data', () => {
    // Vérifie que les données affichées sont celles du mock
    const compiled = fixture.nativeElement;
    expect(compiled.querySelector('p').textContent).toContain('Mocked User (99 ans)');
  });

  it('should call getUser() from UserService', () => {
    // Vérifie que la méthode getUser() du service a bien été appelée
    expect(mockUserService.getUser).toHaveBeenCalled();
  });
});

Explications

• On crée un "spy object" (jasmine.createSpyObj) pour simuler le UserService et on lui donne une fausse méthode getUser().
• On remplace le vrai UserService dans TestBed avec notre version mockée (useValue: mockUserService).
• On simule la réponse du service en forçant une valeur ({ name: 'Mocked User', age: 99 }).
• On teste que les valeurs affichées correspondent bien aux valeurs mockées.
• On vérifie que getUser() a bien été appelé par le composant.

Un Fake Service est une classe qui imite le vrai service, mais elle est écrite directement dans le code du test et ne fait pas d'appels externes. Son but est de remplacer le vrai service tout en gardant une logique réaliste.

Création d'un service

@Injectable({
  providedIn: 'root'
})
export class UserService {
  constructor(private http: HttpClient) {}

  getUser(): Observable<User> {
    return this.http.get<User>('https://api.example.com/user'); // Appel HTTP réel
  }
}

Dans un test unitaire, on ne veut pas appeler l'API, car :

• Ça rendrait les tests lents et instables (si l’API est en panne).
• On veut contrôler ce que l’API retourne pour tester différents cas.

Création de la classe FakeUserService dans le test

class FakeUserService {
  getUser(): Observable<User> {
    return of({ name: 'Titouan', age: 24 }); // Retourne une donnée simulée
  }
}

Ici, on crée une classe qui imite le vrai service. La méthode getUser() retourne une fausse réponse (un Observable avec un utilisateur simulé). Il n'y a pas d’appel HTTP,ce qui rend le test rapide et stable.

Utiliser le Fake Service dans le test

Dans le fichier d'implémentation du test, on remplace UserService par FakeUserService dans le TestBed :

TestBed.configureTestingModule({
  providers: [{ provide: UserService, useClass: FakeUserService }]
});

Puis on écrit les tests :

it('should get user data', () => {
  userService.getUser().subscribe(user => {
    expect(user.name).toBe('Titouan');
    expect(user.age).toBe(25);
  });
});
//... autres tests

Ainsi on teste la vraie logique du composant, sans dépendre de l’API (pas d'appel => test fiable & rapide). On garde une logique réaliste, contrairement à un simple mock.