openclassrooms-student-center / billed-app-fr-front

L'architecture du projet :

Ce projet, dit frontend, est connecté à un service API backend que vous devez aussi lancer en local.

Le projet backend se trouve ici: https://github.com/OpenClassrooms-Student-Center/Billed-app-FR-back

Organiser son espace de travail :

Pour une bonne organization, vous pouvez créer un dossier bill-app dans lequel vous allez cloner le projet backend et par la suite, le projet frontend:

Clonez le projet backend dans le dossier bill-app :

$ git clone https://github.com/OpenClassrooms-Student-Center/Billed-app-FR-Back.git

bill-app/
   - Billed-app-FR-Back

Clonez le projet frontend dans le dossier bill-app :

$ git clone https://github.com/OpenClassrooms-Student-Center/Billed-app-FR-Front.git

bill-app/
   - Billed-app-FR-Back
   - Billed-app-FR-Front

Comment lancer l'application en local ?

étape 1 - Lancer le backend :

Suivez les indications dans le README du projet backend.

étape 2 - Lancer le frontend :

Allez au repo cloné :

$ cd Billed-app-FR-Front

Installez les packages npm (décrits dans package.json) :

$ npm install

Installez live-server pour lancer un serveur local :

$ npm install -g live-server

Lancez l'application :

$ live-server

Puis allez à l'adresse : http://127.0.0.1:8080/

Comment lancer tous les tests en local avec Jest ?

$ npm run test

Comment lancer un seul test ?

Installez jest-cli :

$npm i -g jest-cli
$jest src/__tests__/your_test_file.js

Comment voir la couverture de test ?

http://127.0.0.1:8080/coverage/lcov-report/

Comptes et utilisateurs :

Vous pouvez vous connecter en utilisant les comptes:

administrateur :

utilisateur : [email protected] 
mot de passe : admin

employé :

utilisateur : [email protected]
mot de passe : employee

billed-app-fr-front's Issues

Outdated dev dependencies

The dependencies are outdated, at least 3 major versions behind current releases for jest related packages and testing-library related packages, if it remains like that the project may become irrelevant in the long run.

Inconsistencies between tests descriptions and what is actually tested

Many preexisting tests in "src/tests/Dashboard.js" assess that "When I am on Dashboard page ..." while it's blatantly not the case since the UI is not rendered in the Jest DOM and no testing-library queries are used at all.

Inconsistencies between tests expected date format and rendered data date format

The default export in "src/views/BillsUI.js" renders some HTML code in which date values are formatted to "4 Avr. 04" while the tests in "src/tests/Bills.js" query the DOM for date values formatted as "2004-04-04".

Il manque la méthode POST sur le store mocké...

Ok il faut le faire nous même ca fait partit de l'exercice... Dsl pour cette issue.

faute d'anglais dans le nom d'un test (affichage par date décroissante)

Il y a une faute d'anglais dans un des tests du fichier Bills.js.

Le test indique “Then bills should be ordered from earliest to latest". En anglais “earliest (plus tot) to latest (plus tard)” équivaut à un ordre croissant de dates alors que le code cherche à valider un ordre décroissant, conformément au bug report sur notion qui indique “les notes de frais s'affichent par ordre décroissant” (ce qui est attendu).

Vous pourriez changer le nom du test par “Then bills should be ordered from most recent to oldest”. Moins confusing ;)
Penser à changer le screenshot de la tache Notion également.

NewBill.js : post vs patch

En l'état actuel du code c'est la méthode NewBill.handleChangeFile qui lance le call api POST, tandis que la méthode NewBill.handleSubmit lance un call api PATCH.
Cela pose quelques problèmes :

• lancer un POST à l'upload d'un fichier a-t-il la moindre utilité ?
• de plus si on upload un autre fichier avant de submit le form, on aura deux tickets créés dont un comportant des null sur les champs required
• par rapport au projet, on nous demande de tester la méthode POST sur NewBill, et instinctivement on pourrait penser qu'il s'agit de tester le call lancé au submit, donc au final... le call PATCH. Le cahier des charges n'est donc pas très clair.

Enfin, la gestion des catch sur NewBill oblige l'étudiant à donner dans des solutions compliquées pour tester les erreurs API.
Par exemple :
expect(console.error).toHaveBeenCalled()
ne laisse pas vraiment la possibilité de tester le message d'erreur, et donc de vérifier s'il s'agit d'une erreur 404 ou 500.

Module-scope functions declared at function scope instead

Many functions that should live at module scope are re-declared again and again at function scope (ex. onNavigate in "src/tests/Dashboard.js").

Tests d'exemple d'intégration GET non fonctionnel

Les 3 tests d'intégration GET ne fonctionnent pas (tests/Dashboard.js)

La logique semble pourtant bonne mais le contenu de la page reste sur le dernier test en cours.
Donc l'html retourné par DashboardFormUI(bills[0]) du test précédant.

Après avoir ajouté un reset de celle-ci en début de test :

document.body.innerHTML = "";

On obtient l'html de la page d'erreur, avec comme message : "ReferenceError: fetch is not defined".
Il semblerait que ces tests utilisent donc le store non mocké, et jsdom n'implémente pas fetch il me semble.

L'approche par l'utilisation de

window.onNavigate(ROUTES_PATH.Dashboard);

est donc problématique car on ne lui a pas spécifié notre store mocké.

J'espère être dans l'erreur et que ce problème m'est unique, merci de me tenir informé si c'est le cas.

Les tests en questions pour le contexte :

// test d'intégration GET
describe("Given I am a user connected as Admin", () => {
  describe("When I navigate to Dashboard", () => {
    test("fetches bills from mock API GET", async () => {
      localStorage.setItem("user", JSON.stringify({
        type: "Admin",
        email: "a@a"
      }));
      const root = document.createElement("div");
      root.setAttribute("id", "root");
      document.body.append(root);
      router();
      window.onNavigate(ROUTES_PATH.Dashboard);
      await waitFor(() => screen.getByText("Validations"));
      const contentPending = await screen.getByText("En attente (1)");
      expect(contentPending).toBeTruthy();
      const contentRefused = await screen.getByText("Refusé (2)");
      expect(contentRefused).toBeTruthy();
      expect(screen.getByTestId("big-billed-icon")).toBeTruthy();
    });
    describe("When an error occurs on API", () => {
      beforeEach(() => {
        jest.spyOn(mockStore, "bills");
        Object.defineProperty(window, "localStorage", {
          value: localStorageMock
        });
        window.localStorage.setItem(
          "user",
          JSON.stringify({
            type: "Admin",
            email: "a@a",
          })
        );
        const root = document.createElement("div");
        root.setAttribute("id", "root");
        document.body.appendChild(root);
        router();
      });
      test("fetches bills from an API and fails with 404 message error", async () => {
        mockStore.bills.mockImplementationOnce(() => {
          return {
            list: () => {
              return Promise.reject(new Error("Erreur 404"));
            },
          };
        });
        window.onNavigate(ROUTES_PATH.Dashboard);
        await new Promise(process.nextTick);
        const message = await screen.getByText(/Erreur 404/);
        expect(message).toBeTruthy();
      });

      test("fetches messages from an API and fails with 500 message error", async () => {
        mockStore.bills.mockImplementationOnce(() => {
          return {
            list: () => {
              return Promise.reject(new Error("Erreur 500"));
            },
          };
        });

        window.onNavigate(ROUTES_PATH.Dashboard);
        await new Promise(process.nextTick);
        const message = await screen.getByText(/Erreur 500/);
        expect(message).toBeTruthy();
      });
    });
  });
});

Inconsistent syntax when using promises

The code mixes ES6 and non ES6 syntax when using promises, and the rejected promises are inconsistently handled (ex. "src/app/Store.js", "src/containers/Bills.js" and "src/containers/Dashboard.js")

Bill is wrongfully created when a document is uploaded and we go back to bills list

The Bills API is mocked in 2 different places

There are 2 different mocks for the same API : bills data are mocked in "../fixtures/bills.js" and in "../mocks/store.js", both are used at random in the tests, and the bills are exactly the same in the 2 mocks.