Organisation de 'Sample Test Files' dans Visual Studio et SVN

Question

Ma question concerne les fichiers de test par lesquels je veux dire les fichiers non-code dont dépendent certains de mes tests automatisés (* .xml, * .xls, * .jpg etc). Donc, je vais utiliser exemples de fichiers de test à ne pas confondre avec les fichiers de test signifiant des fichiers de code contenant des tests.

La plupart de mes tests automatisés sont des tests unitaires, mais j'ai également des tests d'intégration dans un seul projet (MyApp.Tests.Integration) qui vérifient le comportement des classes qui interagissent avec des dépendances externes.

Ma collection d'exemples de fichiers de test est contenue dans un autre projet de ma solution appelé MyApp.Tests.TestFiles. Chaque fichier a une action de construction de 'Content' et Copy If Newer 'dans ses propriétés.

Quand je lance mes tests, la solution a été construit et les fichiers sont copiés à mon répertoire de sortie « bin \ Debug » et mes tests d'intégration Renvoyez y.

Le problème qui a déclenché la question était que j'avais transféré mes exemples de fichiers de test dans mon référentiel svn, hébergé en ligne avec une quantité limitée de stockage, à côté de mon code. Les fichiers occupaient une quantité excessive d'espace dans le référentiel. J'ai depuis reconstruit le dépôt et réduit tous les fichiers de test d'échantillon à une taille minimum. Dans la plupart des cas, il est peu probable que les fichiers de test changent, alors que je veux qu'ils soient disponibles dans mon référentiel avec une copie de travail, il n'y a aucune raison de les avoir sous contrôle de version tant que je peux reconstruire MyApp .Tests.TestFiles \ TestFiles structure de répertoire pour exécuter les tests.

C'est le scénario, j'espère que des réponses aux points suivants:

• Y at-il une meilleure façon de travailler avec ces fichiers?
• Serait-il préférable de conserver ces fichiers quelque part en dehors de ma solution? Puis-je conserver tous les fichiers requis dans mon dépôt svn mais pas sous le contrôle de version?
• En savoir plus sur MSBuild peut-il m'aider?

Answer 1

Je doute qu'il y aura un accord sur la «meilleure» façon d'organiser les choses. Je sais que dans mon système SCM, j'aime généralement avoir un seul dossier qui contient un dossier pour le code déployable et le code de test. Disons que je construis Widget et j'ai un DLL appelé MyLibrary. Ensuite, le dossier Widget aura un dossier appelé MyLibrary et un appelé MyLibrary_test. Dans VS je fais la même chose et je garde mon projet de test dans la même solution que mon projet déployable. Je travaille seul afin que les équipes plus grandes puissent trouver d'autres styles d'organisation plus appropriés. Je traite mon code de test de la même manière que le code source déployable. C'est dans le système de gestion de code source. SVN conserve les fichiers de différences, donc conserver des copies versionnées de vos fichiers de test n'est pas si cher. SVN essaie même de garder les deltas sur les binaires mais parfois doesn't work out as well as one mighthope. Je ne crois pas que SVN est conçu pour conserver une dernière copie unique d'un fichier source. L'approche «delta» ne fonctionnerait pas aussi bien. La première fois que vous apportez accidentellement un changement à un fichier de test, vous pouvez revenir en arrière et récupérer la version de travail.