[Teched 2007] Unit Testing Tips and Techniques with Visual Studio 2008 and the .NET Framework
Roy Osherove - SELA Group www.ISerializable.com (blog)
Retour a une activité plus sérieuse. Quelle fut ma surprise en rentrant dans la salle que de voir que le speaker de cette session était Roy Osherove, déjà vu sur une session sur l'agilité lundi (en fait j'ai d'abord vu sa guitare en rentrant dans la salle, en place au milieu de la salle pour sa chanson finale).
Cette session s'est déroulée sur un modèle interactif, sans slides et sans contenu prédéfinit (la première que je vois ici) - approche originale et courageuse devant une salle pleine à craquer devant contenir au moins 300 personnes. Roy a demandé au public de proposer des thèmes autour des tests unitaires et mis ensuite en place un système de vote pour définir le contenu à prioriser.
Voici les thèmes proposés tour à tour par les participants à la session:
- NUnit Vs MBunit Vs MSTest 2008
- Multithreading related tests
- State Based Vs. Interaction Based testing
- Mocks Objects tips and tricks
- When to refactor design for testability
- TypeMock - good or bad
- Web testing in unit tests
- Legacy code testing
- What does TDD mean - how to do it?
- UI Testing
- Unit Vs. Integration testing
- Distributed test running
- LINQ Mocking
- Testing data layers - DB
Les (300) participants ont ensuite voté à main levé pour sélectionner les sujets a prioriser (avec une limite de 5 votes chacun), le tout fait dans un contexte décontracté avec des réponses pleines d'humour.
Voici les réponses de Roy:
UI Testing: Le rôle du développeur est de séparer au maximum la logique d'affichage de la logique métier en utilisant un modèle MVC si possible, rendant le maximum de composants testable via tests unitaires. Le test d'interface graphique a proprement parlé, doit se faire par les humains.
Testing Data Layers: Faut il tester la couche Data? La couche métier l'utilise, donc on pourrai se contenter de tester celle-ci. Mais dans certains cas, il existe bel et bien de la logique dans une base de données: relation, trigger, proc stocks... donc comment valider tout ceci. Exemple: utilisation d'une classe faisant des insertions dans une base de données. A chaque exécution du test, la base de données est polluée, il est donc nécessaire de supprimer les données insérées après. Ceci peut se faire en encapsulant le test dans une transaction .NET, en utilisant un RollBack en fin de test (attention cependant, avec l'utilisation d'entiers auto-incrémentés, le rollback ne decrémente pas l'identifiant, il est nécessaire d'écrire un peu de SQL pour ceci dans la phase de nétoyage du code).
Mocking: Comment tester des objets ayant des dépendances fortes et contraignantes avec d'autres objects en ignorant / simulant ces dépendances - en remplacant l'objet dépendant par un Mock object (exemple fait avec un "Fake object"). J'en reparlerai plus en détail demain durant la session consacrée à ce sujet. Il est possible d'utiliser un Mock dynamique (ex: Nunit.DynamicMock ou RhinoMock) pour faciliter la création de mock: créé automatiquement par le runtime lors de l'exécution du test, nul besoin d'implémentation concrète.
Politique de nommage des tests: Il est important d'utiliser des noms de méthode de test les plus explicites possibles contenant les information MethodeATester_DansQuelContexte_QuAttendre(). Ex: DoSomelogic_NullMsg_ThrowsException()
Test sur du multithreading: Exemple avec l'utilisation d'une librairie TrheadTester développé par Roy (http://weblogs.asp.net/rosherove/archive/2007/06/22/multi-threaded-unit-tests-with-osherove-threadtester.aspx)
NUnit Vs MBunit Vs MSTest: Pour Roy, Aller de NUnit vers MBUnit est très simple et naturel. MBunit est le framework le plus facile a étendre. MSTest est bien pour une utilisation similaire a NUnit (mais uniquement la version 2008, il considère la version 2005 comme n'étant pas assez performante). Il est cependant délicat de passer de MBunit vers MSTest de part un manque d'attributs présents dans MBUnit dont on prend rapidement gout.
La présentation s'est ensuite bien sur terminée par une chanson accompagnée à la guitarre. Avec ce coup-ci comme thématique "le premier test du développeur".
