Programmation PYTHON - Zenk - Security - Repository

Programmation dirigée par les tests
CHAPITRE 12
Dans l’exemple, le protocole d’envoi d’un e-mail est connu et a été mis dans le test du
patch, mais le principe de construction par essai-erreur peut s’appliquer en aveugle
pour des objets non connus, en appelant directement le code client dans le test.
Simulation d’un module complet
Il est parfois nécessaire de simuler un module complet pour couper toute dépendance
à des bibliothèques liées par des directives import. L’interpréteur gère un dictionnaire
où il conserve tous les modules importés. À chaque nouvelle importation, ce
dictionnaire est contrôlé et si le nom (sans chemin) du module apparaît dans la liste
des clés, l’objet de type module n’est pas recréé.
Remplacer un module par un autre module réservé aux tests consiste donc à supprimer
l’entrée de ce module dans le dictionnaire et à en recréer une avec le module
de remplacement.
Il est fortement déconseillé d’utiliser le même nom que le module original : dans certains
cas le patch peut s’activer lorsque ce n’est pas souhaité. Cette situation peut se
produire lorsque le code appelant rencontre le module de patch avant le module réel,
par le jeu des chemins de recherche.
Un nom préfixé par fake_ par exemple, est plus explicite.
Exemple de patch pour le module imaplib :
Bouchon (fakeimaplib.py)
""" ** Bouchon IMAP **
"""
class IMAP4:
def login(sef, user, password):
return True
Unité de test
#!/usr/bin/python
# -*- coding: ISO-8859-15 -*import
sys
# déchargement du vrai module imap si nécessaire
if 'imaplib' in sys.modules.keys():
original_imap = sys.modules['imaplib']
del sys.modules['imaplib']
else:
original_imap = None
399