Validez les envois

Vous savez vérifier ce que le serveur vous envoie, mais comment valider ce que vous envoyez au serveur ? Comment on fait pour tester qu'une requête contient bien le payload nécessaire ?

Installez un groupe à table

Dans la partie Seating de l'application, lorsqu'un serveur souhaite installer des clients à table, il tombe sur cet écran :

Lorsque le serveur clique sur "Seat Party", une requête PATCH est envoyée au serveur :

• l'id de la table est renseigné dans l'URL de la requête

• le nouveau statut et le nombre de clients sont envoyés dans le corps de la requête

Le HttpTestingController que vous avez utilisé dans le chapitre précédent, en plus de permettre de répondre aux requêtes, expose également la requête elle-même, vous donnant accès à ses différentes propriétés. Regardons cela dès maintenant.

Dans le fichier de test de la façade, ajoutez une suite imbriquée "Seat party at table", et créez votre premier test :

describe('Seat party at table', () => {

    it('should update the table on the server', () => {
        
    });
    
});

Pensons à nos trois étapes :

• Arrange : comme précédemment, tout est prêt grâce aubeforeEach

• Act : on appellera la méthode pour envoyer la requête

• Assert : on vérifiera l'URL et le corps de la requête

Commençons par Act :

it('should update the table on the server', () => {
    facade.seatPartyAtTable('table1', 5).subscribe();
});

Pour l'étape Assert, il vous faut l'accès à la requête : vous l'avez avecexpectOne  !

it('should update the table on the server', () => {
    facade.seatPartyAtTable('table1', 5).subscribe();
    const req = httpCtrl.expectOne(`/api/tables/table1/seat`);
});

Grâce à l'objet retourné par  expectOne  (de type TestRequest), vous pouvez en vérifier le body :

it('should update the table on the server', () => {
    facade.seatPartyAtTable('table1', 5).subscribe();
    const req = httpCtrl.expectOne(`/api/tables/table1/seat`);
    expect(req.request.body).toEqual({ status: 'occupied', partySize: 5 });
});

Faites tourner les tests, et vous verrez que celui-ci passe !

Une refactorisation utile

Dans ce test en l'état, on a des "valeurs magiques" : l'identifiant de la table et le nombre de personnes dans le groupe sont passés en valeur brute et à plusieurs endroits. Comme pour tout le reste du code, pour la maintenance et la lisibilité de ces tests, ce n'est pas une bonne pratique. Effectuons dès maintenant la refactorisation pour donner du sens à ces valeurs :

it('should update the table on the server', () => {
    const tableId = 'table1';
    const partySize = 5;
    facade.seatPartyAtTable(tableId, partySize).subscribe();
    const req = httpCtrl.expectOne(`/api/tables/${ tableId }/seat`);
    expect(req.request.body).toEqual({ status: 'occupied', partySize});
});

Du coup, le test a maintenant une étape Arrange !

Vérifiez le nouvel état des tables

Regardons de plus près la méthode de la façade :

seatPartyAtTable(tableId: string, partySize: number): Observable<Table> {
    return this.apiService.seatPartyAtTable(tableId, partySize).pipe(
        tap(updatedTable => {
            const current = this.tablesState();
            const updated = current.map(t => t.id === tableId ? updatedTable : t);
            this.tablesState.set(updated);
        })
    );
}

Lorsque la requête réussit, on voit que la méthode met à jour  tableState  , en mettant à jour la table modifiée (qui est retournée par le serveur). C'est un comportement qu'on voudrait tester, mais comment ? Le piège (dans lequel beaucoup sont tombés) serait d'essayer de lire  tableState  directement…mais on peut mieux faire !

À vous de jouer

Contexte

Voici le test que vous allez implémenter :

it('should mark the table as occupied', () => {
    
});

Consigne

Ici vous aurez besoin des trois étapes :

• Arrange

  • pour qu'une table soit mise à jour, il faut qu'il y en ait une ! — il vous faudra donc un objet Table

  • il faudra charger cette table dans l'application et y avoir accès pour pouvoir la vérifier plus tard

• Act

  • il faudra appeler la bonne méthode de la façade avec les bons arguments

  • vous aurez besoin de répondre à la requête générée avec la Table mise à jour (son statut passer en "occupied"

• Assert

  • vous vérifierez que la table chargée dans l'application a bien été mise à jour

En résumé

• la méthode  expectOne  du  HttpTestingController  retourne un  TestRequest  qui contient, entre autres, le corps de la requête envoyée

• il est important d'éviter les "valeurs magiques" : donnez du contexte en créant des constantes avec des noms sémantiques

• en plus de tester la requête générée, il est important de tester les comportements qui suivent la requête

Après tout ce temps passé à tester le côté "caché" de l'application — les façades, services etc — il est temps de passer du côté "components" de la force !