Écrire des tests unitaires dans un assemblage ou dans un assemblage séparé?

Question

Lors de l'écriture de tests unitaires, placez-vous vos tests dans l'ensemble que vous souhaitez tester ou dans un ensemble de test séparé? J'ai écrit une application avec les tests dans les classes dans un assemblage séparé pour la facilité du déploiement car je peux simplement exclure l'assemblage. Est-ce que quelqu'un y écrit des tests au sein de l'assemblée que vous souhaitez tester et si oui, quelle est la justification?

Answer 1

J'ai une solution unique avec un projet d'interface, un projet de test, un projet de domaine et un projet de données. Quand je publie je viens de publier l'interface, qui ne référence pas les tests afin qu'il ne soit pas compilé.

Editer: La ligne du bas est vraiment que vous ne voulez pas qu'il fasse partie de votre version finale. Vous pouvez réaliser cela automatiquement dans VS en utilisant un projet/assemblage séparé. Cependant, vous pouvez l'avoir dans le même assemblage, mais ne compilez pas ce code si vous utilisez nant ou msbuild. Bit désordonné cependant, garder les choses bien rangées, utiliser un ensemble distinct :)

Answer 2

Dans un assemblage différent. Sinon, votre assembly référencera le framework de test (par exemple Nunit.Framework.dll) et vous devrez l'installer sur la machine du client,

Même si ce que vous expédiez est une bibliothèque, et que vous voulez que votre client voit le tests unitaires comme exemple ou spécification sur l'utilisation des objets que vous fournissez, il y a très peu d'avantages à inclure dans l'assemblage de production.

Answer 3

Ceci est largement débattu sur le net.

Nous utilisons des assemblages séparés et l'attribut InternalsVisibleTo pour aider les assembleurs de testeurs à voir tous les entrailles des assemblages testés. Nous avons tendance à faire un assemblage de test pour chaque assemblage que nous testons.

Answer 4

Je dirais que la seule fois où vous voulez intégrer un code de test dans votre déploiement final, c'est quand le code de test est là pour surveiller et contrôler l'application.

Quitter le code de test dans le déploiement:

• gonflerait le code à aucun avantage réel du tout - tout ce code supplémentaire suivisme qui ne va pas être utilisé tout in situ.
• affecte les versions - publiez-vous une nouvelle version de l'application complète. lorsque ce que vous avez amélioré est uniquement dans le code de test, par ex. une suite de tests est étendue à la suite d'une correction de bogue.
• Vous ne pouvez pas facilement réutiliser le framework de test sur un autre projet - si vous publiez toujours des applications qui sont obstruées par du code de test, tous les projets suivants doivent réutiliser le même code de test. Sinon, vous finissez avec la situation où l'application A utilise v1.2 de la plate-forme de test pour ces aspects de l'application. qui sont communs à toutes vos applications, par ex. une couche de présentation, ou un cadre de logique métier, etc. Et app. B utilise v1.1 du cadre de test, app. C utilise v1.2.1, etc.

Découplage sur le otherhand vous permet de:

• facilement et étendre la mise à niveau de la suite de tests selon les besoins.
• facilement réutiliser la suite de tests sur plusieurs projets.
• utiliser un cadre de test commun à travers plusieurs projets.

HTH

acclamations,

Rob

Answer 5

Vous pouvez les garder dans les assemblées distinctes dans la solution, et les ILMerge plus tard pour le débogage, et ne les ILMerge pas pour la libération.