(BSR)[PRO] test: some new tests for search individual offer #12931
Conversation
|
Visit the preview URL for this PR (updated for commit 28f48c9): https://pc-pro-testing--pr12931-ncanseco-bsr-cypress-5bdngof3.web.app (expires Sat, 06 Jul 2024 12:37:26 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 032d233ee67e1c50d6af12e29c936c7076770eb1 |
scolson-pass
force-pushed
the
ncanseco/bsr-cypress-filters-search-offer
branch
6 times, most recently
from
b83e1e6
to
28c1b25
Compare
There was a problem hiding this comment.
Je trouve qu'on se base énormément sur ce que voit l'utilisateur. De ce que j'avais compris de ce point, on n'était pas censé le faire.
Est-ce qu'au lieu de vérifier ce que contient le tableau, on ne peut pas juste vérifier que l'appel est fait, qu'il fonctionne (202), que le loader est affiché puis retiré ?
Comme ça on sera beaucoup moins dépendant de la data, et ou des changements d'interface.
@AmineLouveau ce que tu décris, c'est ce que les test unitaires et/ou d'intégration doivent vérifier. Ici on fait des tests e2e, de bout en bout, on vérifie donc jusqu'à l'affichage. On respecte la pyramide des tests et on essaye de ne rien laisser passer dans les trous du modèle de Reason (gruyère ou emmental?). Rappel: quand on chargera les données qu'on veut et qu'on utilisera plus les données inadaptées de la sandbox, les données ne changeront plus. Ce qui est indiqué dans les guidelines c'est la description du gherkin, pas le contenu du code que nous vérifions. Est-il nécessaire de repréciser la stratégie des tests avec @Nturchetti et @ncanseco-pass ? |
scolson-pass
changed the title
scolson-pass
force-pushed
the
ncanseco/bsr-cypress-filters-search-offer
branch
from
28c1b25
to
4a73f72
Compare
scolson-pass
force-pushed
the
ncanseco/bsr-cypress-filters-search-offer
branch
7 times, most recently
from
c6a0e19
to
346e4f1
Compare
|
Pour moi c'est ok (forcément) @ncanseco-pass on merge ? |
| }) | ||
|
|
||
| When('I select a date in one month', () => { | ||
| const dateSearch = dayjs().add(30, 'days').format('YYYY-MM-DD') |
There was a problem hiding this comment.
Est-ce qu'il y a vraiment besoin de rajouter une lib uniquement pour ça ?
There was a problem hiding this comment.
que suggères-tu pour que la date du jour + 30 jours au format yyyy-mm-dd soit toujours correcte quel que soit le jour de l'année, la timezone, etc ?
There was a problem hiding this comment.
Complètement d'accord avec Amine, on a déjà date-fns qui devrait suffire (où même l'api Date ?).
@scolson-pass @ncanseco-pass Pour info côté frontend on a pour pratique de minimiser le nombre de librairies qu'on installe.
Chaque librairie c'est de la maintenance en plus, une augmentation de la taille du code téléchargé par les clients, et moins d'homogénéité dans les pratiques de développement.
Par ailleurs, si une librairie ne sert pas dans l'app en production, il vaut mieux mettre le package dans les devDependencies.
There was a problem hiding this comment.
OK, vous avez tout à fait raison, j'étais passé à côté de l'utilisation déjà existante de data-fns que je ne connaissais pas. C'est corrigé/commité. Merci pour les commentaires
scolson-pass
force-pushed
the
ncanseco/bsr-cypress-filters-search-offer
branch
from
346e4f1
to
87a9b4e
Compare
scolson-pass
force-pushed
the
ncanseco/bsr-cypress-filters-search-offer
branch
from
87a9b4e
to
f0bac6e
Compare
WIP fix (BSR)[PRO] test: data modified again in sandbox! (BSR)[PRO] test: data fix (BSR)[PRO] test: event created 30 days later and not 1 month fix removes a comment
scolson-pass
force-pushed
the
ncanseco/bsr-cypress-filters-search-offer
branch
from
f0bac6e
to
db940c5
Compare
scolson-pass
force-pushed
the
ncanseco/bsr-cypress-filters-search-offer
branch
from
068d5ca
to
28f48c9
Compare
But de la pull request
Scénarios ajoutés :
Débuté par @ncanseco-pass terminé par @scolson-pass
Vérifications