Meilleures pratiques de tests unitaires pour les solutions Visual Studio

Question

Salut à tous, j'ai été chargé de réorganiser notre processus de construction ici au travail et j'aimerais commencer à inclure les tests unitaires (nUnit) dans nos projets. Grâce à mes recherches, j'ai une bonne compréhension de la technologie que je vais utiliser, mais je voulais obtenir des conseils sur les meilleures pratiques pour mettre en place ma solution de test et m'assurer que la solution proposée est solide.

Notre principale solution VS 2008 compte environ 4 projets. Pour chaque projet, je vais créer un projet de test unitaire correspondant et les ajouter à notre solution. Je voudrais que nos développeurs commencent à développer cette solution, et tout le code enregistré retournera au tronc (en utilisant SVN). Pour notre processus de construction, j'utiliserai un serveur d'intégration continue pour construire et tester notre code de développement dans le coffre (avec les tests unitaires). Tant que cela se construit, je veux avoir une solution de déploiement qui a mes 4 projets et (mais pas de tests unitaires) et pousser ce code pour QA, par exemple Test | Mise en scène puis finalement la production. Comme je pousse le code dans chaque environnement, mon objectif est de ne pas pousser les projets de tests unitaires avec ce code. D'après ma description, cela ressemble-t-il à un processus typique? Si oui ou non, quelqu'un a-t-il des suggestions pour optimiser ce processus?

Merci.

Answer 1

Pourquoi auriez-vous deux solutions différentes? Utilisez simplement la solution qui inclut les tests unitaires, puis sélectionnez uniquement la sortie des projets de production à expédier vers QA/Test. (Ou si QA/Test reçoit le code source complet, laissez eux encore construire les projets de test unitaires et juste les ignorer.) Avoir plusieurs solutions sonne comme un effort supplémentaire pour aucun gain. Sinon, si vous vraiment voulez une construction sans tests unitaires, vous pouvez avoir une configuration de solution (comme Debug et Release) qui ne construit pas les projets de test unitaires. Dans le menu où vous sélectionnez normalement Debug ou Release, sélectionnez "Configuration Manager ..." puis dans la boîte de dialogue suivante, cliquez sur le menu déroulant "Configuration de la solution active" et choisissez "< Nouveau>" pour en créer un nouveau . Choisissez une configuration appropriée à partir de laquelle copier (probablement Release), puis décochez simplement les projets de test unitaires.

Personnellement, je reste juste construire tout bien ...

Answer 2

Personnellement, je n'aime pas les tests de séparation à partir du code testé. Si le code est écrit pour être vraiment testable à l'unité, je trouve qu'il est préférable d'avoir le code de test unitaire pour une classe particulière dans le même fichier que la classe elle-même. De cette façon, il est plus simple pour les développeurs de suivre les tests unitaires lorsqu'ils introduisent des changements ou de nouvelles fonctionnalités dans le code. Cependant, des projets de tests unitaires distincts sont presque nécessaires lorsque des dépendances inter-systèmes doivent être prises en compte. Séparer les tests (intégration plutôt que unités tests) donne la liberté de configuration d'environnement d'exécution de test et évite l'introduction de parties de code indésirables dans la base de code principale. D'autre part, vous devrez utiliser [assembly:InternalsVisibleTo("test_assembly_name")] pour activer le code de test pour accéder aux membres internes.

La compilation conditionnelle peut être utilisée pour éviter le code de test des versions de version. Bien que, dans certains scénarios spéciaux, il peut être utile d'inclure le code de test unitaire même dans une version de version et permettre à l'application de réaliser un autotest. Exemple: une interface est déclarée avec un contrat sémantique que l'implémenteur doit fournir des attributs spécifiques aux méthodes/propriétés/à la classe implémentant l'interface.Dans le cas où l'application est capable de charger certains modules d'extension (assemblages inconnus au moment de la compilation), une fonctionnalité d'auto-test peut aider à garantir que le système entier fonctionnera.