Catégorie: Test

Si vous avez des résultats désespérant dans votre couverture de code, ce n'est peut-etre pas votre faute

En effet, si vous utilisez du code généré (et notamment les datasets typés), ceux-ci ne génèrent pas toujours correctement l'attribut GeneratedCodeAttribute.

C'est un bug connu qui est normalement corrigé dans vs2010 (j'avoue ne pas avoir testé encore).

A noter qu'un nouvel attribut sera disponible avec le framework 4.0, il s'agit de [ExcludeFromCodeCoverage].

Un peu de patience et nous aurons des superbes taux de couverture de code

Si vous tentez d'automatiser l'extraction de la couverture de code, comme je l'ai indiqué dans ce billet, vous pouvez obtenir une erreur, du genre de la suivante :

System.IO.FileLoadException was unhandled 
  Message="A procedure imported by 'Microsoft.VisualStudio.Coverage.Analysis, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' could not be loaded." 
  Source="WindowsFormsApplication1" 
  FileName="Microsoft.VisualStudio.Coverage.Analysis, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
  FusionLog=""

» Lire la suite!

Suite de mon précédent billet :

Le xml obtenu a la tête suivante :

» Lire la suite!

Le billet que je voulais écrire semble trop long, je vais donc le décomposer en 2 billets...

Comme vu dans ce billet : La couverture de code avec Visual Studio, visual studio peut nous générer un rapport de couverture de code une fois les tests unitaires joués.

Dans un processus d'intégration continue il est envisageable de programmer l'exécution des tests unitaires à date précise via une tache msbuild. Il est également possible de générer un rapport de couverture de code automatiquement. Cependant, pour le consulter, on sera obligé d'ouvrir un visual studio et de charger les tests correspondant.

Nous allons voir ici une solution pour extraire par code le résultat de la couverture de code afin de l'envoyer par exemple par mail au développeur.

» Lire la suite!

Comme dit dans Wikipédia, La couverture de code (en anglais code coverage) est une mesure utilisée en génie logiciel pour décrire le taux de code source testé d'un programme. Ceci permet de mesurer la qualité des tests effectués.

Visual Studio (notamment dans sa version Visual Studio Team System Test Edition) permet de mesurer la couverture du code de nos tests unitaires.

Prenons par exemple cette classe :

   1: public class Class1

   2: {

   3:     public int DoStuff()

   4:     {

   5:         return 10;

   6:     }

   7:  

   8:     public void DoStuffJamaisAppelee()

   9:     {

  10:         throw new NotImplementedException();

  11:     }

  12: }

et la classe de test associée :

   1: [TestClass]

   2: public class UnitTest1

   3: {

   4:     [TestMethod]

   5:     public void TestMethod1()

   6:     {

   7:         Class1 class1 = new Class1();

   8:         int result = class1.DoStuff();

   9:         Assert.AreEqual(10, result);

  10:     }

  11: }

On a beau avoir tous nos tests qui passent :

On voit bien, en observant le code de notre classe de test, que seule la méthode DoStuff est couverte alors que la méthode DoStuffJamaisAppelee n'est jamais testée.

Dans ce cas simple, il est facile de se rendre compte qu'il faut rajouter un test appelant la méthode DoStuffJamaisAppelee pour être bien sur que l'ensemble de notre code est couvert par des tests unitaires. Mais si le code se rallonge, comment être bien sur que l'on oublie rien ?

» Lire la suite!

Sans rentrer dans le débat de "Pourquoi vouloir tester une méthode privée", il est possible de tester unitairement des méthodes privées.

» Lire la suite!

L'inconvénient d'un web service est qu'il a besoin d'un serveur web pour s'exécuter, comme IIS ou le serveur web de visual studio.

Or, bien que cela soit possible de lancer à la main le serveur à travers visual studio et d'effectuer des tests, cela devient problématique pour toute utilisation automatisée ou souhaitant tourner dans un environnement où aucun serveur web n'est lancé.

Comment faire alors pour tester son web service ?

» Lire la suite!

Les personnes qui écrivent des tests unitaires connaissent en général ce pattern qui consiste à organiser son test en 3 parties :

• Arrange => initialiser les objets mis en jeu par le test
• Act => Exécuter la méthode que l'on souhaite tester
• Assert => Vérifier que les résultats sont conforme aux attentes

Je n'ai pas vu de traduction officielle de cette abréviation.

Que pensez-vous de :

• Arranger
• Agir
• Auditer

En avez vous d'autres à proposer ?

Bien sur, l'objectif est de garder les 3 A :)

Tester sa couche d'accès aux données (DAL) est toujours un calvaire pour le développeur. La principale raison réside dans la nature même d'une base de données et dans sa fonction de persistance d'état.

Or, un test doit pouvoir se baser sur un contexte connu et le fait de tester des opérations CRUD sur sa base de données va forcément modifier ce contexte. On en déduit deux axes principaux :

• Avoir un contexte connu => i.e. avoir des valeurs dans la base de données
• Ne pas modifier le contexte => i.e. restaurer l'état de la base comme au début du test

Quelles sont les différentes pistes que nous pouvons explorer pour résoudre ce problème ?

» Lire la suite!