Comment les gens ont-ils configuré leurs projets pour Visual Studio et comment référenez-vous l'application testable?
À l'heure actuelle, j'ai ajouté un projet distinct créant un .dll à ma solution contenant tous les cas de test et références nunit.framework, et il fait également référence au fichier principal .exe dès le débogage / dossier où vs génère la Sortie.
Mais je ne sais pas si c'est une bonne idée - ou quelles sont les meilleures pratiques, tout le monde veut partager ses pratiques?
5 Réponses :
Cela vous semble très bon pour moi - vous pouvez distribuer ou déployer votre application sans l'assemblage de test et le nunit, mais toujours tout tester. Pratique la pratique standard.
J'ai utilisé un dossier séparé pour tous mes tests lorsque vous les utilisez dans un projet. Ensuite, vous pouvez supprimer le dossier facilement lors de la construction réelle si vous le souhaitez.
J'ai aussi fait ce que vous dites avec un projet séparé. Je pense que c'est bien.
Typiquement, j'ai une solution contenant un certain nombre de projets sans aucun test d'unité dans cette solution principale - c'est la solution intégrée en mode de libération pour une version vraie.
Pour un projet spécifique, j'ai une solution séparée qui contient le projet que je souhaite un test d'unités (et des dépendants) et un projet MyProjectName.UnitTestSTS qui abrite tous les tests de l'unité pour ce projet. Ces projets de test d'unités sont ensuite configurés dans une machine d'intégration continue pour obtenir en mode de débogage, puis les tests fonctionnent.
fonctionne bien pour moi.
En supposant que le projet de test soit dans la même solution que le (s) projet (s) à tester, une petite amélioration pourrait être d'ajouter une référence au projet sous test plutôt qu'au binaire dans le dossier de débogage.
En plus de ce qui a été mentionné ici, j'utilise souvent également le InternalsVissibleto Attribut d'assemblage Pour rendre les classes internes de l'assembly que je passe visible à l'ensemble de test, c'est-à-dire qu'ils peuvent également être testés directement.
Selon le cadre d'isolation de votre choix, vous devrez peut-être également que les internes de votre assemblée sous test sont visibles aux composants-cadres d'isolation pour pouvoir se moquer / supporter certains comportements internes.
Je ne pense pas qu'il y ait quelque chose de mal à livrer des DLL contenant du code qui prouve que même la DLL dans un envulginissement de la production fonctionne toujours dans les paramètres établis :). En cas d'erreurs étranges, vous pouvez toujours exécuter les tests de l'unité avec la DLL de sortie et voir si quelque chose s'est cassé de manière étrange. Pour cette raison et parce que je n'aime pas avoir deux fois le nombre de projets dans une solution, je préfère ajouter un dossier de tests dans chaque projet où tout le code de test de l'unité va. Simple et efficace.
Cordialement,
Sebastiaan