TEST: The application should be quickly usable on consulting an item (see #383)

[Antoine-Guyot]

Content

@benel @albertelombo Ajout des tests permettant de répondre au scénario du ticket #383

---

Checklist

Please check that your pull request is correct:

• Each commit:
  • [ ] corresponds to a contribution that should be notified to users,
  • [ ] does not generate new errors or warnings at compile or test time,
  • [ ] must be attributed to its real authors (with correct GitHub IDs and correct syntax for multiple authors).
• The title of a commit should:
  • [ ] begin with a contribution type
    • FEATURE for a behaviour allowing a user to do something new,
    • FIX for a behaviour which has been changed in order to meet user’s expectations,
    • SCENARIO for examples showing a given behaviour,
    • TEST when it concerns an acceptance test of a given behaviour,
    • PROCESS for a change in the way the software is built, tested, deployed,
    • DOC when it concerns only internal documentation (however it is better to combine it with the contribution that required this documentation change),
  • [ ] be followed by a colon (:) with one space after and no space before,
  • [ ] be followed by a title (written in English) as short, as user-centered and as explicit as possible
    • If it is a feature, the title must be the user action (beginning with a verb, and please not manage),
    • If it is a fix, the title must describe the intended behavior (with should).
  • [ ] ends with a reference to the corresponding ticket with the following syntax:
    • (closes #xx) if xx is a feature ticket (and the commit is a complete implementation),
    • (fixes #xx) if xx is a fix ticket (and the commit is a complete fix),
    • (see #xx) otherwise,
• Each committed line is:
  • [ ] useful (it would not work if removed)
    • if it is a comment line, its information could not be conveyed by better variables and function naming, better code structuring, or better commit message,
  • [ ] related to this very contribution (feature, fix...),
  • [ ] in English (with the exception of Gherkin scenarios in French and resulting steps),
  • [ ] without any typo in variable, class or function names,
  • [ ] correctly indented (spaces rather than tabs, same number of characters as in the rest of the file).

[Antoine-Guyot]

@benel

J'ai mis à jour mon commit en suivant vos recommandations, je pense que tout est bon.

[benel]

@Antoine-Guyot @albertelombo

Bonne nouvelle : vos tests passent. Par contre votre contribution est sur deux commits au lieu d'un seul...

Notez que ce sera un peu plus difficile car vous travaillez sur la branche principale... Vous voyez comment faire ?

[Antoine-Guyot]

@benel

J'ai eu quelques difficultés mais j'ai réussi à rassembler mes changements en un seul commit. Cependant j'ai récupéré tous les autres commits avec le rebase, je ne sais pas si c'était la meilleure façon de faire.

[benel]

J'ai eu quelques difficultés mais j'ai réussi à rassembler mes changements en un seul commit. Cependant j'ai récupéré tous les autres commits avec le rebase, je ne sais pas si c'était la meilleure façon de faire.

Ce n'est pas le plus commode pour l'intégrateur (en effet, vous avez modifié les commits existants ce qui en fait de nouveaux commits qui seraient intégrés avec un merge ou un rebase). Mais maintenant que votre contribution est dans un seul commit, je vais pouvoir me débrouiller avec un cherry-pick.

[benel]

Ah, je viens de comprendre, vous avez le rebase à l'envers (ça m'arrive aussi de temps en temps d'intervertir les deux branches, il faut dire que c'est dans le sens inverse du merge)... Votre commit ne s'est pas inséré au-dessus de l'historique mais en dessous. Au lieu de faire : officiel1 > officiel2 > officiel 3 > dev1 Vous vous retrouvez avec : dev1 > officiel1 > officiel2 > officiel3.

Heureusement que cherry-pick est là...

[benel]

Intégré en tant que 549fbb9d6c8fffbb0d79710d8b5555c5b3779aff. 🎉