12/13/2010 2:52:03 PM
Analystik
Posts: 2
|
Bonjour,
Je viens de terminer le visionnement des vidéos qui sont super en passant et bien que je trouve le produit génial, une bonne coche au dessus des nunit de ce monde, il reste encore le problème cricial des tests units en général, la duplication du code et de la maintenance ce qui les rends couteux et ce, même après la livraison (dans notre cas en tout cas).
Durant le développment, il faut coder deux fois, une fois pour le code et une fois pour les tests et ça, des dizaines sinon des centaines de fois durant le processus de développment, spécialement quand les règles d'affaire ne sont pas stable du début à la fin et même au-dela comme c'est notre cas et ça doit être le cas pour n'importe quel développment agile en fait. C'est très couteux tout ça et je me demande comment les développeurs peuvent avoir la discipline de toujours corriger les unit tests.
Après la livraison, comme nos modules et services sont segmentés pour être indépendant, les chance de brisé quelque chose d'autre que ce que nous modifions sont pratiquement nul mais il faut tout de même retoucher et le code et les tests du code en question car si on a à retoucher le code, ça veut dire que soit le test n'était pas assez exhaustif ou les règles d'affaire ont changé.
Donc, en bout de ligne, on se retrouve à maintenir beaucoup plus de choses que si on ne faisait pas de test unitaire et jusqu'à mainenant, même si on n'utilise pas le test unitaires à leur plein potentiel, aucun des bugs trouvés en prod jusqu'à maintenant n'aurait été détecté par des tests unitaires donc, c'est encore plus difficile à justifier leurs utilisations.
L'autre problématique c'est qu'il faut codé C# avant T# et non l'inverse....en non juste T# ce qui est assez déplaisant pour un développeur.
Pensez vous que ça sera possible un jour de codé seulement en T# nos projets? Genre on met des critère en attributs (paramétrisable) au dessus des méthodes et propriétés et on code le contenu en fonction des attributs par exemple avec des snippets auto-généré ou quelque chose du style.
Merci
Eric Plante
|
|
|
0
• permalink
|
12/13/2010 4:50:26 PM
Ludovic Dubois
Administrator
Posts: 159
|
Bonjour.
En fait, cela dépend de l' "unit" dans "unit test". Il peut y avoir des tests de très bas niveau comme des tests de très haut niveau !
Plus le niveau est haut, moins il y a de redondances.
Cela dépend aussi de comment les tests sont écrits. Si c'est pour répéter le code a tester dans le test, le test ne vaut pas grand chose (surtout si c'est en utilisant du copier/coller) !
L'idéal est de raisonner sur l'objectif du test, donc de la déclaration à tester et écrire des tests pour valider l'objectif, puis le code d'affaires pour atteindre cet objectif écrit en code (T#, évidemment  ).
En passant, je donne un cours sur les tests unitaires en Microsoft.NET au CRIM 
Quand à coder C# avant T#, non... ce n'est pas nécessaire. Dans la vidéo, c'est ce que j'ai fait pour expliquer avant tout le genre de code que je voulais tester pour montrer les possibilités de T#. Mais en fait vous devriez coder en T# avant C#.
Plus exactement, en réalité, voici comment je procède:
- Écrire le squelette du code à tester (seulement la déclaration et pour que cela compile afin d'avoir intellisense dans les tests, en passant pour l'instant Intellisense en T# ne fonctionne qu'avec les déclarations provenant des DLLs, pas encore à partir des projets de la solution) .
- Écrire le code de test (en T#) d'un test le plus normal (happy path).
- Écrire le code à tester pour que ce premier test passe.
- Réflechir au cas testé et décider des critères pour représenter le cas.
- Ajouter la clause When au test
- Prendre les autres cas que T# Tests Explorer indique un à un en les écrivant et en modifiant le code testé pour qu'il passe (qu'ils passent tous)
Quant à la dernière question, il existe des snippets dans T# pour coder les cas les plus classiques. De plus, il est compatible C# v2.0 et donc il est possible de compiler n'importe quel projet. Seulement, pour l'instant, les designers pour WinForms... ne sont pas supportés (mais T# supporte des fichiers .cs, s'ils sont en C# 2.0).
|
|
|
0
• permalink
|
12/14/2010 7:59:25 AM
Analystik
Posts: 2
|
Bonjour,
n'empêche que toutes les méthodes qui prennent un int en paramêtre et / ou retourne un int doivent toutes faire les tests de base sur les int 0, > 0, < 0, MaxInt, > MaxIn, MinInt, < MinInt par exemple et pourrait être automatisé; le reste dépend des règles d'affaires bien sur mais c'est des tests à part.
De plus, il reste quand même que c'est deux projets, deux fichiers et de multiples méthodes/propriété à géré par fonctionnalité ce qui est plutôt désagréable à travailler et peu ergonomique donc demande un plus grande disipline que si le développeur n'avais qu'une seule méthode à géré et d'ajouter des critères et des attributs pour ce qui est spécifique à sa règle d'affaire par exemple.
edited by Analystik on 14/12/2010
<em>edited by Analystik on 14/12/2010</em>
|
|
|
0
• permalink
|
12/14/2010 9:57:29 AM
Ludovic Dubois
Administrator
Posts: 159
|
Il existe des produits qui automatisent les tests mais, personnellement, je n'en veux pas car ils créent les tests à partir du code source et non pas de l'intention. Ainsi, s'il y a des bogues, ils vont générer des tests qui passent quand le bogue est présent!
Effectivement, cela fait 2 projets, mais cela permet de séparer la logique d'affaire de ses tests car on ne livre pas les tests.
Autrement, le problème est d'indiquer les cas à tester. Ca va encore assez bien pour des valeurs simples, mais dès que cela se complique, plus possible de les passer en attributs (cela ne fonctionne qu'avec des constantes!)
C'est à méditer... 
|
|
|
0
• permalink
|