docs: add e2e test development process #264
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Clara Ni <[email protected]>
SergeCroise
reviewed
Feb 3, 2025
| @@ -31,6 +31,15 @@ Cela se fait par des appels API en typescript avant de lancer le test à proprem | |||
|
|
|||
| Les données testées sont les mêmes en local ou via l'intégration continue. | |||
|
|
|||
| #### Process de développement des tests e2e | |||
There was a problem hiding this comment.
Suggested change
| #### Process de développement des tests e2e | |
| #### Processus de développement des tests e2e |
SergeCroise
reviewed
Feb 3, 2025
| - certaines parties du test devront être mockées le temps que la fonctionnalité soit entièrement développée mais à la fin des développements, le test e2e devra être complet et les données mockées devront avoir disparu. Les modifications finales à faire dans le test pour retirer le mocking seront normalement minimes (uniquement changer les expected values). | ||
| - les cas de test et les parcours utilisateur devront être définis en amont, au moment du refinement du ticket, avant le PIP. Ils pourront être proposés par Aymen ou un.e PO, et devront être validés par Aymen, le.la PO compétent.e et des devs front. | ||
| - si un test e2e touche à la config des tests e2e, à l’architecture du projet (typiquement le snapshoting) ou présente un risque de ralentir la CI, un atelier de refinement devra être organisé pour consulter les personnes en charge de l'architecture du projet et de la CI, notamment la team devops. | ||
|
|
||
| #### Atomicité d'un test | ||
| Chaque test doit être **atomique** : il se suffit à lui même et ne peut pas être divisé. |
There was a problem hiding this comment.
Suggested change
| Chaque test doit être **atomique** : il se suffit à lui même et ne peut pas être divisé. | |
| Chaque test doit être **atomique** : il se suffit à lui-même et ne peut pas être divisé. |
SharglutDev
approved these changes
Feb 4, 2025
| - This workflow helps prevent immediate regressions after a feature release, enhances the entire team's proficiency in E2E testing, and avoids excessively long PRs that would introduce entire E2E test suites at once. | ||
| - It is acceptable for E2E tests to be partial during development, even if their implementation increases ticket size and development time. | ||
| - Some parts of the tests will need to be mocked while the feature is still under development. However, by the end of development, the E2E test must be complete, and all mocked data should be removed. The final modifications to eliminate mocking should be minimal (typically limited to updating expected values). | ||
| - Test cases and user journeys should be defined in advance, during ticket refinement, before the PIP. They may be proposed by Aymen or a Product Owner (PO) and must be validated by Aymen, the relevant PO, and frontend developers. |
There was a problem hiding this comment.
Maybe it could be nice to explain what Aymen does on the project ?
There was a problem hiding this comment.
Indeed we should replace Aymen by QA
Maymanaf
approved these changes
Feb 4, 2025
woshilapin
approved these changes
Feb 4, 2025
| @@ -31,6 +31,15 @@ Cela se fait par des appels API en typescript avant de lancer le test à proprem | |||
|
|
|||
| Les données testées sont les mêmes en local ou via l'intégration continue. | |||
|
|
|||
| #### Process de développement des tests e2e | |||
| Les tests e2e sont implémentés de manière itérative, et livrés en même temps que les développements. A noter que: | |||
There was a problem hiding this comment.
Suggested change
| Les tests e2e sont implémentés de manière itérative, et livrés en même temps que les développements. A noter que: | |
| Les tests e2e sont implémentés de manière itérative, et livrés en même temps que les développements. À noter que: |
| - on accepte que les tests e2e soient partiels le temps des développements et que le développement des tests alourdisse la taille des tickets et le temps de développement. | ||
| - certaines parties du test devront être mockées le temps que la fonctionnalité soit entièrement développée mais à la fin des développements, le test e2e devra être complet et les données mockées devront avoir disparu. Les modifications finales à faire dans le test pour retirer le mocking seront normalement minimes (uniquement changer les expected values). | ||
| - les cas de test et les parcours utilisateur devront être définis en amont, au moment du refinement du ticket, avant le PIP. Ils pourront être proposés par Aymen ou un.e PO, et devront être validés par Aymen, le.la PO compétent.e et des devs front. | ||
| - si un test e2e touche à la config des tests e2e, à l’architecture du projet (typiquement le snapshoting) ou présente un risque de ralentir la CI, un atelier de refinement devra être organisé pour consulter les personnes en charge de l'architecture du projet et de la CI, notamment la team devops. |
There was a problem hiding this comment.
Suggested change
| - si un test e2e touche à la config des tests e2e, à l’architecture du projet (typiquement le snapshoting) ou présente un risque de ralentir la CI, un atelier de refinement devra être organisé pour consulter les personnes en charge de l'architecture du projet et de la CI, notamment la team devops. | |
| - si un test e2e touche à la configuration des tests e2e, à l’architecture du projet (typiquement le snapshotting) ou présente un risque de ralentir la CI, un atelier de refinement devra être organisé pour consulter les personnes en charge de l'architecture du projet et de la CI, notamment la team devops. |
| - on accepte que les tests e2e soient partiels le temps des développements et que le développement des tests alourdisse la taille des tickets et le temps de développement. | ||
| - certaines parties du test devront être mockées le temps que la fonctionnalité soit entièrement développée mais à la fin des développements, le test e2e devra être complet et les données mockées devront avoir disparu. Les modifications finales à faire dans le test pour retirer le mocking seront normalement minimes (uniquement changer les expected values). | ||
| - les cas de test et les parcours utilisateur devront être définis en amont, au moment du refinement du ticket, avant le PIP. Ils pourront être proposés par Aymen ou un.e PO, et devront être validés par Aymen, le.la PO compétent.e et des devs front. | ||
| - si un test e2e touche à la config des tests e2e, à l’architecture du projet (typiquement le snapshoting) ou présente un risque de ralentir la CI, un atelier de refinement devra être organisé pour consulter les personnes en charge de l'architecture du projet et de la CI, notamment la team devops. |
There was a problem hiding this comment.
Doit-on utiliser le terme anglais "refinement" dans la version française? On peut remplacer par un "atelier de réflexion" ou "atelier de conception"... mais "refinement" fait probablement partie du jargon agiliste donc je suis ok quelque soit la résolution de mon commentaire.
There was a problem hiding this comment.
https://fr.wikipedia.org/wiki/Raffinement
ou alors mettre le terme refinement entre parenthèses, par exemple:
atelier de réflexion (refinement)
ou
atelier de conception (refinement)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.