Ajouter des tests

[Luthaf]

Parce que c'est bien quand même, et ca éviterai de passer en prod des erreurs 500 parce que tester toutes les pages c'est long.

La doc Django pour ce problème : https://docs.djangoproject.com/en/dev/topics/testing/overview/

[oliverpool]

Je n'ai quasiment aucune expérience dans le domaine, mais je pencherai plus pour des tests "haut-niveau" (déroulé d'un scénario: enregistrement utilisateur, validation de l'email, connexion, déconnexion).

Après quelques recherches, je suis tombé sur cette bibliothèque qu'en penses-tu ?

[Soundy25]

Hello, pour les tests automatisés, j'y connais pas grand chose, mais suis pas mal affuté sur les recettes de livrables avant mise en prod. Je ne sais pas si vous en êtes à pouvoir relivrer un truc qqpart, mais ça serait cool, car je n'ai pas progressé dans l'installation d'un contexte de dev chez moi ...

J'ai quelques jours de congés là et ai prévu de me rendre un peu dispo pour ce projet.
En quoi pourrais-je vous aider ?

@+ Soundy

[Luthaf]

@oliverpool Ce que tu propose, c'est des tests fonctionnels, et ça peut être intéressant aussi. Je pensais plus à des tests unitaires ici.

@Soundy25 On a pas de recette de livrable automatisée, on pourrait construire quelque chose sur basé sur Docker, mais je ne pense pas que ça en vaille le coup. Pour l'installation, ouvre un sujet avec les messages d'erreur, ou envoie moi un mail. Et pour les trucs à faire, c'est comme tu le sens !

[Soundy25]

Oui, j'imagine bien que l'automatisation d'une recette n'est pas à l'ordre du jour sur ce projet. ^^

[oliverpool]

@Luthaf : ok, mais j'avoue ne pas vraiment arriver à savoir ce qui doit être testé...

@Soundy25 : ça peut être cool si tu indique toutes les erreurs que tu rencontres lors de l'installation, pour qu'on en profite pour améliorer le wiki^^

[oliverpool]

PS: depuis Django 1.7 il y a eu quelques changements:

• le fichier tests/ini.py est inutile
• il faut que les fichiers de tests soit nommés: test_*.py
• les tests sont alors lancés via ./manage.py test generator.tests

[Luthaf]

@Luthaf : ok, mais j'avoue ne pas vraiment arriver à savoir ce qui doit être testé...

Pour les tests unitaires, le comportement des fonctions. Du style, j'envoie une requête de login, je suis bien logué derrière. Le problème des tests unitaires (ou en tout cas de la lib que tu proposais) est qu'il faut modifier les tests dès que l'on touche au contenu du HTML.

[oliverpool]

Certes (quoique on a pas besoin d'être hyper-précis concernant le HTML: on peut seulement vérifier qu'un texte est bien présent dans la page, ou que la BDD a été modifié comme attendu).
En revanche permet de vérifier que les pages HTML fonctionnent (si un champ à le mauvais 'name' par exemple).

Je pensais créer les "conditions du test" via un pseudo remplissage HTML et vérifier que tout s'est bien passé en lisant directement la BDD.