C'est difficile de faire des tests unitaires qui couvrent tout. C'est tres tres facile de faire des tests unitaires en python mais sur mes programmes, malgre la palanquee de test, il y a toujours des cas non testes.
On peut eventuellement utiliser des outils de couverture de code (valider que les tests unitaires exercent tous les chemins) mais je ne suis pas sur ca suffise.
Typiquement, comme les type sont dynamiques, je me retrouve souvent a abuser un peu de ca, et ca peut faire mal:
def f( a ):
if not type(a) is type([]): a = [ a ]
# now, treat a as a list
def g( b ):
if type(b) is type([]):
for e in b:
g(b)
Dans ces deux cas, g et f acceptent deja deux types d'arguments (a noter pour les pythonistes que g peut s'ecrire plus simplement avec map).
En fait, je pense que ce n'est pas un bon style de programmation parce que c'est un peu dangereux. C'est avec ce genre de connerie qu'on se retrouve avec des chemins d'execution hyper complexes et qu'on peut lever une exception au mauvais moment.
[^] # Re: le python c'est bon
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Python 2.4. Évalué à 2.
On peut eventuellement utiliser des outils de couverture de code (valider que les tests unitaires exercent tous les chemins) mais je ne suis pas sur ca suffise.
Typiquement, comme les type sont dynamiques, je me retrouve souvent a abuser un peu de ca, et ca peut faire mal:
def f( a ):
if not type(a) is type([]): a = [ a ]
# now, treat a as a list
def g( b ):
if type(b) is type([]):
for e in b:
g(b)
Dans ces deux cas, g et f acceptent deja deux types d'arguments (a noter pour les pythonistes que g peut s'ecrire plus simplement avec map).
En fait, je pense que ce n'est pas un bon style de programmation parce que c'est un peu dangereux. C'est avec ce genre de connerie qu'on se retrouve avec des chemins d'execution hyper complexes et qu'on peut lever une exception au mauvais moment.