Tests

Sauf indication contraire, toutes les commandes qui sont données doivent être effectuées à partir du dossier des sources de Porphyry.

1. Sauvegarder ses modifications et revenir à la dernière révision officielle

Au cas où vous auriez fait des modifications hors-commits que vous voudriez garder pour plus tard (par exemple sur des fichiers de configuration), lancez la commande :

git stash

Laissez de côté vos contributions, revenez à la branche maître (v7) et mettez la à jour par rapport à l'entrepôt officiel (Hypertopic/Porphyry) :

git checkout v7
git remote add official https://github.com/Hypertopic/Porphyry.git
git pull official v7

2. Lancer une version modifiable de Porphyry

• Installez les dépendances (vous avez environ une minute pour vous préparer un ☕️) :

  npm install 
  

• Lancez Porphyry :

  npm start
  

3. Mettre en place son environnement de test

Vous utilisez "Docker Toolbox" (parce que vous êtes sous Windows Famille) ?

Affichez l'adresse IP de votre machine du point de vue de votre machine virtuelle :

ipconfig

L'adresse se trouve dans la section Carte Ethernet VirtualBox à la ligne Adresse IPv4. Si elle est différente de 192.168.99.1, il faudra par la suite remplacer cette dernière par la véritable adresse.

Lancez la commande suivante :

docker run --rm --volume "$(pwd)":/app --tty --env APP_HOST="http://192.168.99.1:3000" benel/cucumber-capybara --retry 2

Normalement certaines étapes doivent prendre quelques secondes et passer au "vert". Vous devez avoir 8 scénarios qui réussissent ou sont instables (passed ou flaky), 1 en attente d'implémentation (pending), mais aucun qui échoue (failed).

Une fois que cela fonctionne, créez un alias (sans l'option retry afin de pouvoir la modifier) :

alias cucumber='run --rm --volume "$(pwd)":/app --tty --env APP_HOST="http://192.168.99.1:3000" benel/cucumber-capybara'

Vous utilisez un docker plus "standard" ?

Lancez le résultat de la commande suivante :

docker run --rm --volume "$(pwd)":/app --tty --env APP_HOST="http://$(hostname):3000" benel/cucumber-capybara --retry 2

Normalement certaines étapes doivent prendre quelques secondes et passer au "vert". Vous devez avoir 8 scénarios qui réussissent ou sont instables (passed ou flaky), 1 en attente d'implémentation (pending), mais aucun qui échoue (failed).

Une fois que cela fonctionne, créez un alias (sans l'option retry) :

alias cucumber='docker run --rm --volume "$(pwd)":/app --tty --env APP_HOST="http://$(hostname):3000" benel/cucumber-capybara'

Expérimenter le cycle de développement guidé par les tests

Maintenant que vous savez que tous les tests existants passent, commencez le processus de développement guidé par les tests : ajoutez un test qui échoue. Normalement, vous en avez préparé un : le scénario du fix #143.

Au cas où il y aurait eu des contributions officielles depuis votre clone, appliquez votre contribution à la suite de la dernière contribution officielle (en remplaçant fix-143 par le nom de votre branche) :

git rebase v7 fix-143
git checkout fix-143

Lancez les tests avec cucumber --retry 2 et vérifiez qu'ils échouent :

Failing Scenarios:
cucumber features/attribute_set.feature:12 # Scénario: ayant pour valeur des URI

10 scenarios (1 failed, 1 pending, 8 passed)
100 steps (2 failed, 6 skipped, 1 pending, 91 passed)
0m56.242s

La fin des messages est explicite : vous avez désormais un scénario qui échoue... Et il s'agit précisément de celui que vous avez ajouté. C'est normal... Rappelez vous du cours : vous venez de vous fixer un objectif de développement 👍

Remontez dans les messages jusqu'au début de ceux qui s'affichent en rouge :

expected to find text "https://www.aube-champagne.com/fr/poi/hotel-de-vauluisant-musee-de-vauluisant/#cdt-information" in "VITRAUX\naliceSe déconnecter\n Retour à l'accueil\nDescription\nAttributs du document\nvisite\thttps\t\nHistoire des religions\nHistoire de l'art\nundefined"

Cela demande un peu d'entraînement pour repérer les différentes parties du message, mais une fois vos yeux "accommodés", vous voyez que vous auriez dû avoir https://www.aube-champagne.com/fr/poi/hotel-de-vauluisant-musee-de-vauluisant/#cdt-information et qu'à la place vous avez eu seulement https. Visiblement, l'URI a été tronquée au niveau de :. Sachant que c'est également le séparateur entre l'attribut et sa valeur, il devient évident que le logiciel fait du zèle : il tronque également la valeur de l'attribut à chaque occurence de :.

Il faut désormais repérer ou se trouve le code à modifier. Nous verrons lors de la prochaine séance comment est structuré une application React. En attendant, rendez vous dans src/components/Item/Item.jsx, dans la méthode _submitAttribute et repérez la ligne contenant la méthode split. Testez le problème puis une solution dans node (en mode interactif) :

node
"visite:https://www.utt.fr/".split(':')
"visite:https://www.utt.fr/".match(/([^:]*):(.*)/).splice(1)
^d

Modifiez en conséquence le code et relancez les tests.

Vous avez désormais 9 scénarios réussis (passed ou flaky) ? Bravo, vous avez fait votre première itération en TDD 🥇 Pour fêter l'événement, amendez votre contribution et publiez la :

git add src/components/Item/Item.jsx
git commit --amend -m "FIX: Add a resource to an item as a link (fixes #143)"
git push --force

Avez-vous remarqué le petit symbole à côté de votre demande d'intégration ? Cliquez dessus pour voir à quoi cela correspond. À quoi cela sert-il ? Que signifient les initiales CI dans le nom "Travis CI" ?