Evidemment, tu me sors unr erreur qui ne peut être détectée qu'à l'exécution.
Je n'ai jamais prétendu qu'on pouvait se passer des tests unitaires avec les langages à typage statique et c'est pas pour rien qu'il existe jUnit en Java.
Le typage statique apporte simplement un niveau de sécurité supplémentaire.
Maintenant observe le code suivant:
l=range(35)
>>> def sum(l):
... j=0
... for i in l:
... j=j+i
... return j
...
>>> a=sum(l)
>>> sum(range(35))
595
Imagines que la fonction sum soit placée dans un module m1, qu'un développeur utilise cette fonction dans son propre module m2 et l'inclue dans une fonction plus spécifique qui accepte encore "l" en paramètre.Imagines que cette fonction soit mal documentée (l'erreur est humaine et la paresse encore plus), ou encore que celui qui utilise m2 implémente un algorithme complexe pour construire la liste en paramètre à la fonction de m2.
Du coup la liste passée en paramètre en prod est.
l=[1,"2",3]
(Les test d'intégrations ne pouvant être jamais être exhaustifs en raison de la combinatoire)
Résultat des courses en prod
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4, in sum
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Avec un langage typé statiquement, tu as déclaré un type tableau d'entiers en paramètre des fonctions et l'algorithme de l'utilisateur devra accepter des int ou ne compilera pas(éventuellement après un cast s'il manipule des Object ou d'autres types).
Et là on parle des types de base, mais on a le même type de contrôles avec des classes ou des interfaces alors que le duck typing ne vérifiera rien et te lanceras des exceptions tout pareil.
Imagines que tu aies affaire à des dizaines de composants avec de nombreuses dépendances et tu augmentes la probabilité de ce genre d'erreur, surtout si tu intègres des modules externes que ton équipe n'a pas développé. Là où la documentation fait foi et où on se base sur des conventions implicites qui sont sujettes à négligence ou oubli, le typage explicite et uniforme montre sa supériorité.
Avec Java, les exceptions sont également vérifiées à la compilation et sont explicitées alors qu'avec un langage typé dynamiquement tu dois te coltiner tout l'arbre de dépendance pour vérifier dans la doc ou dans le code toutes les exceptions qui sont susceptibles d'être levées.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
Je n'ai jamais prétendu qu'on pouvait se passer des tests unitaires avec les langages à typage statique et c'est pas pour rien qu'il existe jUnit en Java.
Le typage statique apporte simplement un niveau de sécurité supplémentaire.
Maintenant observe le code suivant:
Imagines que la fonction sum soit placée dans un module m1, qu'un développeur utilise cette fonction dans son propre module m2 et l'inclue dans une fonction plus spécifique qui accepte encore "l" en paramètre.Imagines que cette fonction soit mal documentée (l'erreur est humaine et la paresse encore plus), ou encore que celui qui utilise m2 implémente un algorithme complexe pour construire la liste en paramètre à la fonction de m2.
Du coup la liste passée en paramètre en prod est.
l=[1,"2",3]
(Les test d'intégrations ne pouvant être jamais être exhaustifs en raison de la combinatoire)
Résultat des courses en prod
Avec un langage typé statiquement, tu as déclaré un type tableau d'entiers en paramètre des fonctions et l'algorithme de l'utilisateur devra accepter des int ou ne compilera pas(éventuellement après un cast s'il manipule des Object ou d'autres types).
Et là on parle des types de base, mais on a le même type de contrôles avec des classes ou des interfaces alors que le duck typing ne vérifiera rien et te lanceras des exceptions tout pareil.
Imagines que tu aies affaire à des dizaines de composants avec de nombreuses dépendances et tu augmentes la probabilité de ce genre d'erreur, surtout si tu intègres des modules externes que ton équipe n'a pas développé. Là où la documentation fait foi et où on se base sur des conventions implicites qui sont sujettes à négligence ou oubli, le typage explicite et uniforme montre sa supériorité.
Avec Java, les exceptions sont également vérifiées à la compilation et sont explicitées alors qu'avec un langage typé dynamiquement tu dois te coltiner tout l'arbre de dépendance pour vérifier dans la doc ou dans le code toutes les exceptions qui sont susceptibles d'être levées.