[FR] Faire des tests en python Pyconfr 2012

Atelier sur les tests en Python lors de Pyconfr, rappels sur les niveaux/types de tests, quelques conseils

Transcript

1. Faire des tests en Python FELD Boris - Pyconfr 2012
2. Requirements $> pip install nose sst
3. Something that is untested is broken.
4. About me Étudiant en école d’ingénieur Évangeliste python et fan de l’open- source @lothiraldan (sur twitter, bitbucket, github, google plus, un peut partout en fait...)
5. Plan Rappels Mise en pratique Retour et conseils
6. Rappels
7. C’est quoi un test ? La vérification d’un objectif. Simplement: On effectue une action, on vérifie que le résultat est le résultat attendu.
8. Des tests oui... Mais automatisés Le problème avec les tests «à la main»: Il faut trouver une main disponible Dans ce cas il faut automatiser les tests
9. Pourquoi faire des tests ?
10. Pourquoi faire des tests ? Assurer la qualité du produit finit. Vérifier qu’il n’y a pas de régression. Détecter les bugs.
11. Oui mais surtout... C’est un moyen de gérer la peur pendant le développement - Kent Benck Au moindre doute, le développeur peut lancer les tests.
12. Les tests Terminologie: La partie de l’application que l’on teste est souvent appelé «SUT» (System Under Test). Que tester ? Tout... Sauf les librairies/services externes.
13. Caractéristiques attendues Reproductibles Laisser un environnement clean Un test unitaire doit être isolé de son environnement
14. Niveaux et types de tests Niveau de test : périmètre, qu'est-ce que tu teste Types de test : comment tu veut tester
15. Niveaux de tests Tests unitaires Tests d’intégration Tests système Tests d’acceptation
16. Test unitaire Unité SUT
17. Test d’intégration SUT Unité existante Unité existante Unité
18. Test système SUT Unité Unité Unité Unité Unité Unité
19. Types de tests Tests fonctionnels Tests de non-régression Tests de performance Tests de sécurité
20. Étapes d’un test Préparer l’environnement Initialiser les variables Faire l’appel Vérifier l’environnement et la réponse Nettoyer l’environnement
21. TDD
22. Test Driven Development Popularisé par Kent Benck auprès de la communauté SmallTalk. La base du TDD repose sur un cycle : Red - Green - Refactoring. Quelques règles aussi.
23. Organisation des tests Les tests sont organisés en TestCase. Ils constituent un ensemble logique de tests (le même SUT, ...). Les TestCase sont organisés en TestSuite. Ils constituent là aussi un ensemble logique de TestCase (tous les tests, tous les tests unitaires, ...).
24. Unittest Module python faisant partie de la librairie standard. Inspiré par JUnit.
25. Exemple avec unittest import random import unittest class TestSequenceFunctions(unittest.TestCase): def setUp(self): self.seq = range(10) def test_shuffle(self): # make sure the shuffled sequence does not lose any elements random.shuffle(self.seq) self.seq.sort() self.assertEqual(self.seq, range(10)) # should raise an exception for an immutable sequence self.assertRaises(TypeError, random.shuffle, (1, 2, 3)) def test_choice(self): element = random.choice(self.seq) self.assertTrue(element in self.seq) def test_sample(self): with self.assertRaises(ValueError): random.sample(self.seq, 20) for element in random.sample(self.seq, 5): self.assertTrue(element in self.seq) if __name__ == '__main__': unittest.main()
26. Les méthodes d’assertion On a le choix : AssertEqual/AssertNotEqual AssertTrue/AssertFalse AssertIn/AssertNotIn AssertRaises
27. Mise en pratique
28. Étape 1, présentation de l’application Librairie de gestion de budgets partagés Qui n’a jamais eut besoin de gérer un budget à plusieurs lors d’une sortie ou d’un week-end ? Qui a payé ? Combien ? Pour qui ? Qui doit combien et à qui ?
29. Étape 2, premiers tests Créons un test qui signifie ce qu’on veut en suivant les principes du Test Driven Development (test d’abord).
30. Tester les interactions Unité SUT Unité existante
31. La manière «classique» Unité SUT Unité existante Etat 1
32. On remplace ! Unité SUT Unité existante
33. On remplace ! Unité SUT Unité existante
34. On remplace ! Unité SUT Unité existante Fausse unité
35. Pourquoi remplacer une unité ? Remplacer un comportement non déterministe (l'heure ou la température ambiante). Si l’unité a des états difficiles à reproduire (une erreur de réseau par exemple). Si l'initialisation de l’unité est longue (ex : création d'une base de données). Si l’unité n'existe pas ou si son comportement peut encore changer. S'il est nécessaire d'inclure des attributs et des méthodes uniquement à des fins de test. Pour isoler les tests. Pour éviter qu’un bug introduit dans une unité fasse échouer toute la suite de tests.
36. On remplace ! Cela consiste à utiliser des mocks, des objets avec des réponses prédéfinies. Ainsi il est plus simple de «simuler» des erreurs, des cas difficiles à configurer, ...
37. Test Coverage Quelle partie de mon code est testée ?
38. Rapport en HTML
39. Selenium Test d’interface en lançant un vrai navigateur. Puis interaction avec le navigateur via une socket. Lent mais rendu réel.
40. SST from sst.actions import * go_to('http://www.pycon.fr/2012/') element = assert_text_contains('logo', 'PyConFR 2012')
41. Conseils 1 bug = 1 test Partager efficacement les résultats des tests Mettre en place un outil d’intégration continue (jenkins, travis-ci).
42. Tests anti-pattern Les boucles dans les tests, surtout si il y a un assert dedans Les tests avec beaucoup d’asserts Les tests avec des chemins no relatifs (ça marche sur ma machine).
43. Testing legacy code
44. Quand le stagiaire me dit que les tests, “c’est pour ceux qui savent pas coder” LJDC