Vous avez vu les modules pour faire les tests, mais dès que vous allez vouloir faire des tests sérieux, vous allez vous heurter à la dure réalité.
La réalité est que pour tester, il vous faut la réalité.
Après avoir vu pytest, un outil typiquement pythonique sont les doctests, des tests unitaires intégrés dans les docstrings.
Les tests unitaires font partie de ces “bonnes pratiques” que tout le monde semble appliquer sur le net. Tous les devs hypes parlent de tests unitaires : les conférences, les blogs, les tutos, les livres, whooooo !
Dans la vraie vie vivante, on croise pourtant peu de gens qui les utilisent vraiment. On les retrouvent surtout dans les gros projets et les grosses boîtes, et encore.
Créer des routes dans l’urlconf juste pour les tests unitaires n’est pas très propre, heureusement on peut utiliser des urls de test complètement séparées.
Je ne fais plus de tests unittaires sans pytest, et je me retrouve souvent à rentrer les mêmes paramètres de la commande encore et encore. Parfois, quand j’autilise des wrappers tels que django-pytest et pytest-django (ça s’invente pas), je ne peux même pas passer d’arguments directement à py.test.
On peut y remedier en créer un fichier de config à la racine du projet.
Et si on pouvait rendre les tests plus simples à écrire et à lire, aussi simple qu’un assert, mais un résultat plus clair que unittest en sortie ?
Comme nous l’avons vu avec les vues ou les collections, Python 2.7 vient avec pas mal de bonus issus directement de la branche 3. En voici quelques autres. Tout ceci n’est bien sûr ni nouveau ni exhaustif, mais je m’aperçois que peu de personnes le savent.
Parfois il est utile de spammer son terminal jusqu’à ce que mort s’en suive.
