Introduction à l'Intégration Continue, Présentation de MsTest et de Static

Citation:

---

Nous allons présenter l'intégration continue dans le monde Microsoft.NET en deux parties:
Cette première partie servira non seulement comme une introduction à l'intégration continue (pourquoi la mettre en place, ce qu'elle apporte, quels outils allons-nous utiliser, ...) puis se concentrera sur une description très détaillée de deux des outils utilisées :

* MsTest pour l'écriture de tests automatisés
* Static Code Analysis pour valider le code écrit.

---

http://pedautreppe.developpez.com/tu...code-analysis/

J'ai reçu quelques questions par message privé. Ci-joint les questions et les réponses

Dans une solution tu crées autant de projet developpement que de projet Test? Où crées tu un seul Projet Test? Faut-il les/le créer dans la solution ou dans une solution à part?
Pour ma part, j'je trouve intéressant que les projets de test soient une copie conforme des projets "business". Par copie, j'entends qu'ils respectent la même nomenclature de nommage et d'organisation (ce qui sous-entend que les projets de test sont refactorés au même rythme que les projets business).
Attention même rythme != en même temps.
Le code et les tests doivent être un filet de sécurité : si on refactore le code : on ne modifie pas les tests, ils nous garantissent la non-régression du code avec les modifications que l'on a faite. Une fois qu'on refactore les tests, alors le code ne bouge pas : c'est lui qui joue le rôle de garant de non-régression. Dans certains cas évidemment, nous sommes obligés de toucher aux deux en même temps (changement d'API, de nommage, ...) A essayer de limiter cependant.

Bref si j'ai 10 projets business, j'aurais alors 10 projets de tests, et avec la même hiérarchie de namespace à l'intérieur. Les tests doivent en effet être vue comme une documentation à part entière de notre code et doit donc être facilement accessible. Si je veux atteindre les tests de la classe "MaSociete.MonProjet.Business.GestionEmployees.Adresse.cs" alors je vais directement dans la classe de tests "MaSociete.MonProjet.Tests.TU.GestionEmployees.AdresseTest.cs".

Solution dédiée ou non. Débat en cours chez nous. Voici nos avantages / inconvénients ("évidemment" les avantages de les laisser dans la même solution sont des inconvénients pour le choix de les sortir) :
Avantages 1 seule solution
- A tout moment je peux compiler l'intégralité de mon code (business = code, test = code). Sinon je dois m'assurer de compiler mon code business avant de compiler mes tests (à moins de jouer sur des pré/post conditions de build qui peuvent complexifier un peu l'environnement de travail).
- En agile, nous allons souvent travailler en TDD (développement piloté par les tests). Ceci implique de passer en permanence des tests vers le business. On doit donc en rendre le passage le plus simple / rapide possible.


Avantages de plusieurs solutions
- Temps de compilation : compiler 30 projets au lieu de 15 sera probablement deux fois plus lent. Nous utilisons de plus chez nous de l'AOP au niveau de nos tests, c'est à dire de la post-compilation pour réaliser des pré/post conditions sur nos tests. Si la technique est très intéressant en terme d'efficacité et de quantité de code écrit, cela ralentit encore le processus de compilation.


Ma préférence va clairement vers une seule solution pour en faciliter la maintenance et le "fonctionnement" en TDD. Cela dépend probablement des projets et des équipes.

Est-ce qu' une User Story peut contenir d'autres User Story? Avantages/Inconvénients?
De nouveau à voir selon votre implémentation et votre équipe.
Personnellement chez nous oui et cela nous amène de nombreux avantages. Je préciserais en disant qu'une User Story possède d'autres User Stories et des Work Items (plus techniques).

Quand un client nous demande une fonctionnalité, cette fonctionnalité représente une User Story. Mais nos analystes vont l'analyser et la découper en User Stories plus fines: US "Gestion des employés" = US "Ajouter un employé" + US "Edit" + US "Delete" + US "Visualiser" + US "Gestion des préférences des employés" + ...
A l'inverse, si le client nous demande une US "fine" du type "Pouvoir choisir si un employé reçoit des avertissements en HTML ou en TEXT" alors nos analystes vont la rattacher à une US de "plus haut niveau", c'est à dire "Gestion des préférences" ou "Gestion des employés".

Cela représente l'avantage de fournir une découpe en domaines tant pour le client que pour l'équipe.
Cela facilite la visualisation de l'avancement du projet (et des domaines respectifs)
Cela permet aussi aux développeurs de sentir davantage ce sur quoi ils travaillent pour le moment : ce n'est plus 1/100..00 du projet global (autrement dit 1 tâche "perdues" parmi 10.000 autres) mais une tâche des 50 nécessaires pour réaliser un domaine particulier.

Cette découpe / rattachement nous permet en fait de mobiliser davantage l'équipe sur un objectif concret et les aide à mieux concevoir l'application : il est plus facile de mettre en place un design propre et simple dans une application si l'on sait quelles sont les tâches qui y sont liées à court terme.

Chez nous :
- regroupement en domaines de haut niveau (gestion des personnes, financier, statistiques, gestion des documents, ...)
- dans chaque domaine (voir sur plusieurs domaines) : découpe en "projets" concret (une US qui va contenir plusieurs US)
- chaque US : découpe en Work Item (fonctionnel et/ou technique) de granularité fine (de 1h à 2j)

Attention la granularité est à trouver selon les équipes : trop petite, elle peut entraîner des coûts de gestion important. Trop grosse, elle peut rendre floue l'avancement du projet et va impliquer un besoin de reporting pour l'équipe.


Sous une User Story tu y ajoutes des works items backlog(developpement et test). Normalement tu clos une userstory quand tous les workitems associés sont clos. Ma question est : faut-il créer autant de workitem de test qu'il y a de workitem de developpement (WI test = WI Dev)?
Ma réponse est simple : nous ne créons pas de WI de test :-)
Petite parenthèse, nous travaillons avec des testeurs fonctionnels : ils ne codent pas de tests automatisés.

En fait chaque tâche (WI) doit être testée : que ce soit une tâche fonctionnelle (si je clique sur OK, alors mon employé est sauvegardé) ou purement technique (remplacer le bouton de la page TOTO par un contrôle de plus haut niveau).

Nous travaillons en fait en nous appuyant sur un workflow de développement. Ce workflow est matérialisé chez nous par l'utilisation d'un KANBAN mural sur lequel nous collons nos POST-IT représentant les WI, mais peut tout aussi bien être matérialisé dans un outil de gestion de tâches (TFS WorkItems, JIRA, Mantis, ...). Nous pourrons parler par la suite de l'avantage du visuel (post-it, affichages, ...) sur l'informatique.

Par conséquent dès qu'une tâche (WI) est terminée, elle passe dans un statut "A tester", et elle ne sera "Terminée" qu'une fois celle-ci testée.
La User Story correspondante sera alors également close quand les WI associés seront clos.

Même remarque que pour la question précédente : attention au coût de gestion de la multiplicité des tâches.

Mais doit on vraiment toutes les tester sachant qu'une méthode A peut en appeler un B donc du meme coup tester B? Dans ma solution VS j'ai 14 projets et un paquet de classe et méthode qui en découlent. Comment savoir si cette méthode doit etre testée? En général tout ce qui est interface je ne teste pas sachant que les web-test le feront. Dois-je le faire en Unit Test tout de meme?
Chez nous, seuls les tests unitaires "provoquent" le calcul de la couverture de code. Les WebTests sont une manière d'automatiser (et donc de limiter) le travail de nos testeurs.
Le principal point d'attention est le temps: si un TU = 1 ou 5ms, alors un WebTest = 1 ou 5 seconde.
Un des "objectifs" que l'on doit garder en tête est de garder un temps d'intégration continue rapide (30mn c'est déjà long quand on parle de fedback rapide). Alors imaginons 1000 tests de 5 secondes, ce n'est pas gérable.
Bref un WebTest doit se concentrer sur de l'interface uniquement, et non pas compenser un manque de TU.

Maintenant que dois-t-on tester ? C'est un grand débat.
Certains te diront que l'on ne teste que l'API publique de notre projet. Certes mais nous avons pas mal de code private ou internal.
Et de plus si on teste une méthode publique qui utilise 50 autres méthodes en interne, peut-on vraiment parler de test UNITAIRE ?

De notre côté nous essayons de tester au plus bas niveau en utilisant également les accesseurs et l'attribut InternalsVisibleTo fournis par .NET de façon à pouvoir atteindre les méthodes private et internal. Nous utilisont également une bibliothèque de mock (RhinoMock dans notre cas) de façon à pouvoir nous soustraire de certains comportement.

Il n'y a pas de règle absolue cependant. Et selon le cas, je testerais soit la méthode A et la B, ou que la A.
Disons que tes tests sur la méthode B vont probablement vérifier tous les cas aux limites de la méthode alors que les tests de la méthode A vont se contenter du cas par défaut de la méthode B.