formations/python/formation/testsunitaires.txt

154 lines
3.2 KiB
Plaintext
Raw Permalink Normal View History

2013-01-08 11:15:45 +01:00
Tests unitaires et pile d'appels
=================================
Les tests automatiques sont un complément à la déclaration des types.
2013-05-15 10:47:55 +02:00
que tester, quoi tester ?
2013-01-08 11:15:45 +01:00
- que les composants interagissent bien entre eux
- que les unités (fonctions, objets...) réagissent bien à une entrée spécifique
- que le code se comporte de la manière attendue dans des environnements différents
(systèmes d'exploitation, etc...)
2013-05-15 10:47:55 +02:00
les types de tests :
2013-01-08 11:15:45 +01:00
- tests unitaires
- tests fonctionnels
- tests d'acceptation
- tests d'intégration
Quel outil utiliser ?
- la :doc:`stdlib` propose le module :mod:`unittest`
.. module:: py.test
:synopsis: outil de test unitaires de la pylib
- :mod:`py.test` est **le plus simple** (plus simple que unittest)
http://pytest.org/latest/
::
def test_simple():
"test si ma_fontion renvoie bien 3"
assert ma_fontion(2) == 3
- `py.test` utilise `assert` et `raises`
- `unittest` necessite de faire sytématiquement une classe, puis `assertEqual()`
- :mod:`doctest` est plus simple mais charge trop les docstrings
.. todo:: écrire un test unitaire avec `py.test` pour la fonction suivante
- installer le paquet `python-pytest`
- écrire un fichier avec une fonction dedans
::
def double(x):
return x*2
- écrire un fichier commençant par `test_` qui teste les fonctions du fichier
2013-05-15 10:47:55 +02:00
options utiles dans `py.test`
2013-01-08 11:15:45 +01:00
------------------------------
::
py.test --tb=no
py.test --tb=short
py.test -x (dernière erreur)
py.test -s (c'est comme nocapture en fait)
py.test -x --nocapture --pdb
py.test -xl --pdb
py.test -k test_simple
2013-05-15 10:47:55 +02:00
utiliser la pile d'appel pour débugger
2013-01-08 11:15:45 +01:00
---------------------------------------
2013-05-15 10:47:55 +02:00
utiliser la pile d'appels, elle se lit de bas en haut. Il est possible de
2013-01-08 11:15:45 +01:00
provoquer cette pile d'appels.
::
import traceback
traceback.print_exc()
2013-05-15 10:47:55 +02:00
traiter une exception avec
2013-01-08 11:15:45 +01:00
::
try:
...
except:
import traceback
traceback.print_exc()
else:
bla bla
finally:
bla bla
2013-05-15 10:47:55 +02:00
créer le plus possible ses propres exceptions spécifiques au programme
2013-01-08 11:15:45 +01:00
2013-05-15 10:47:55 +02:00
utiliser le module :mod:`pdb`
2013-01-08 11:15:45 +01:00
.. module:: pdb
:synopsis: debugger de la lib standard
::
import pdb
pdb.set_trace()
depuis py.test :
::
import pytest
def test_function():
...
pytest.set_trace() # invoke PDB debugger and tracing
Remarquons que :mod:`pdb` utilise le module :mod:`cmd`, voir :ref:`cmdlabel` qu'on a déjà vu précedemment
::
(Pdb) h
Documented commands (type help <topic>):
========================================
EOF bt cont enable jump pp run unt
a c continue exit l q s until
alias cl d h list quit step up
args clear debug help n r tbreak w
b commands disable ignore next restart u whatis
break condition down j p return unalias where
Miscellaneous help topics:
==========================
exec pdb
Undocumented commands:
======================
retval rv
(Pdb)
2013-05-15 10:47:55 +02:00
last but not least :
2013-01-08 11:15:45 +01:00
utiliser pylint ou pychecker
::
apt-get install pylint