C # - Exclusion des tests unitaires de la version finale de votre projet

Question

Comment procédez-vous habituellement pour séparer votre base de code des tests unitaires associés ? Je connais des personnes qui créent un projet distinct pour les tests unitaires, que je trouve personnellement déroutant et difficile à maintenir. D'autre part, si vous mélangez le code et ses tests dans un seul projet, vous vous retrouvez avec des fichiers binaires liés à votre infrastructure de test unitaire (que ce soit NUnit, MbUnit ou autre) et vos propres fichiers binaires côte à côte.

Cela convient très bien pour le débogage, mais une fois que je construis une version publiée , je ne veux plus du tout que mon code fasse référence au framework de test unitaire .

Une solution que j'ai trouvée consiste à inclure tous vos tests unitaires dans les directives #if DEBUG - #endif: quand aucun code ne fait référence à un assemblage de test unitaire, le compilateur est suffisamment intelligent pour omettre la référence dans le code compilé.

Existe-t-il d'autres options (peut-être plus confortables) pour atteindre un objectif similaire?

Answer 1

Je préconise définitivement de séparer vos tests d'un projet distinct. C’est la seule façon d’aller à mon avis.

Oui, comme Gary vous oblige à tester le comportement à l'aide de méthodes publiques plutôt que de jouer avec les entrailles de vos classes

Answer 2

Comme le soulignent les autres, un projet de test séparé (pour chaque projet normal) est un bon moyen de le faire. En général, je reflète les espaces de noms et crée une classe de test pour chaque classe normale avec 'test' ajouté au nom. Ceci est pris en charge directement dans l'EDI si Visual Studio Team System peut générer automatiquement des classes et des méthodes de test dans un autre projet.

Si vous souhaitez tester des classes et des méthodes avec l'accesseur 'interne', n'oubliez pas d'ajouter la ligne suivante au fichier AssemblyInfo.cs pour chaque projet à tester:

[assembly: InternalsVisibleTo("UnitTestProjectName")]

Answer 3

Le framework .Net after v2 possède une fonctionnalité utile dans laquelle vous pouvez marquer un assembly avec l'attribut InternalsVisibleTo qui permet à l'assembly d'être accessible à un autre.
Une sorte de fonctionnalité d'assemblage de tunneling.

Answer 4

Une autre alternative à l'utilisation de directives de compilation dans un fichier ou à la création d'un projet séparé consiste simplement à créer des fichiers .cs supplémentaires dans votre projet.

Avec un peu de magie dans le fichier de projet lui-même, vous pouvez dicter que:

1. Les DLL nunit.framework ne sont référencées que dans une version de débogage et
2. vos fichiers de test ne sont inclus que dans les versions de débogage

Exemple d'extrait .csproj:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   ...

   <Reference Include="nunit.framework" Condition=" '$(Configuration)'=='Debug' ">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\debug\nunit.framework.dll</HintPath>
   </Reference>

   ...

   <Compile Include="Test\ClassTest.cs" Condition=" '$(Configuration)'=='Debug' " />

   ...
</Project>

Answer 5

Je recommanderais un projet distinct pour les tests unitaires (ainsi que d'autres projets pour les tests d'intégration, les tests fonctionnels, etc.). J'ai essayé de mélanger du code et des tests dans le même projet et je l'ai trouvé beaucoup moins facile à gérer que de les séparer en projets distincts.

Le maintien d’espaces de noms parallèles et l’utilisation d’une convention de nommage judicieuse pour les tests (par exemple, MyClass et MyClassTest) vous aideront à maintenir la base de code maintenable.

Answer 6

Tant que vos tests sont dans un projet séparé, les tests peuvent référencer la base de code, mais la base de code n'a jamais à référencer les tests. Je dois demander, ce qui est déroutant à propos de la maintenance de deux projets? Vous pouvez les conserver dans la même solution d’organisation.

La partie compliquée, bien sûr, est lorsque l’entreprise compte 55 projets dans la solution et que 60% d’entre eux sont des tests. Comptez-vous chanceux.

Answer 7

Je mets les tests dans un projet séparé mais dans la même solution. Certes, dans les grandes solutions, il peut y avoir beaucoup de projets mais l’explorateur de solutions est assez bon pour les séparer et si vous donnez des noms raisonnables, je ne pense pas vraiment que ce soit un problème.

Answer 8

Pour chaque projet, un projet .Test correspondant contient des tests.

E.g. pour l'assemblage appelé, par exemple "Acme.BillingSystem.Utils", il y aurait un assemblage de test appelé "Acme.BillingSystem.Utils.Test".

Excluez-le de la version d'expédition de votre produit en n'envoyant pas cette dll.

Answer 9

J'ai toujours conservé mes tests unitaires dans un projet séparé pour qu'il soit compilé dans son propre assemblage.

Answer 10

Une chose à prendre en compte est que les versions de VisualStudio antérieures à 2005 ne permettaient pas aux projets d'assembly EXE d'être référencés à partir d'autres projets. Donc, si vous travaillez sur un projet hérité dans VS.NET, les options sont les suivantes:

• Placez les tests unitaires dans le même projet et utilisez la compilation conditionnelle pour les exclure des versions validées.
• Déplacez tout vers les assemblys dll afin que votre fichier exe ne soit qu'un point d'entrée.
• Contournez l'EDI en piratant le fichier de projet dans un éditeur de texte.

La compilation conditionnelle sur trois est la moins sujette aux erreurs.

Answer 11

Je suis tout à fait d’accord avec tout le monde pour dire que vous devez séparer les tests de votre code de production. Toutefois, si vous insistez, vous devez définir une constante de composition conditionnelle appelée TEST, et envelopper toutes vos classes de test d'unité avec un

#if TEST
#endif

d’abord pour vous assurer que le code de test ne se compile pas dans un scénario de production. Ceci fait, vous devriez pouvoir soit exclure les dlls de test de votre déploiement de production, soit même mieux (mais avec une maintenance plus importante), créer un NAnt ou un MSBuild pour la production qui se compile sans les références aux dlls de test.

Answer 12

Je crée toujours un projet Acme.Stuff.Test distinct, compilé séparément.

L'argument inverse est le suivant: pourquoi voulez-vous passer les tests? Pourquoi ne pas livrer le test? Si vous livrez les tests avec un testeur, vous avez un certain niveau de test d'acceptation et d'autotest livré avec le produit.

J'ai entendu cet argument plusieurs fois et y ai réfléchi, mais personnellement, je garde toujours les tests dans un projet séparé.

Answer 13

Si la balise #if (DEBUG) permet de "valider" la version " Pourquoi auriez-vous besoin d’un projet séparé pour les tests? La nunit LibarryA / B exemple (oui, je sais que c'est un exemple) fait cela. Actuellement aux prises avec le scénario. Avait utilisé un projet séparé, mais cela semble éventuellement permettre certaines améliorations de la productivité. Toujours hummin et hawin.