Comment structurer des tests unitaires pour une application GUI en utilisant C # et NUnit

On m'a demandé de réaliser un petit projet parallèle pour fournir une application simple à l'un de nos clients. Normalement, je travaillerais sur du code back-end où j'aurais compris tous mes besoins de test, et je n'ai pas encore eu le plaisir douteux d'écrire des tests pour l'interface graphique, donc je ne sais pas trop comment je dois configurer le code de test et les outils pour un EXE.

Mon premier réflexe a été d'inclure simplement les tests avec le code d'application, mais cela nécessiterait de fournir un certain nombre de dépendances spécifiques aux tests, que j'ai été spécifiquement chargé de ne pas envoyer au client. Je ne suis pas non plus en mesure de retirer de l'argent pour un outil de test spécialement conçu, je dois donc utiliser les outils que j'ai à portée de main ( StoryQ , RhinoMocks et NUnit), ce qui devrait vraiment être plus que suffisant pour tester le comportement d'une application GUI simple. Donc, pour autant que je puisse voir, cela me laisse essayer de trouver un bon équilibre entre garder la conception vraiment simple ou délibérément suringénierie pour les tests. Il semble que je crée l'application avec la logique métier dans une bibliothèque distincte et que je teste la bibliothèque comme je le ferais habituellement, ou que je trouve un autre mécanisme pour me permettre d'exécuter l'exécutable sans casser des modules supplémentaires que la conception de l'application ne fait pas. vraiment besoin.

Edit:
Veuillez noter que cette question concerne la façon de structurer la relation entre NUnit et mon exécutable - par opposition à une DLL - et non pas comment séparer la présentation et la logique métier.
/Éditer

Ma question est donc:

1. Existe-t-il une méthode spécifique / recommandée pour configurer une application graphique simple avec des tests unitaires pour me permettre de vérifier correctement l'état et le comportement, en utilisant les outils dont je dispose, et sans recourir à une ingénierie excessive?
2. Ai-je oublié quelque chose de fondamental sur la façon dont NUnit doit être invoqué / configuré lors du test d'un EXE (par opposition à une DLL)?
3. Pouvez-vous me fournir ou me diriger vers des exemples illustrant comment réaliser tout cela?

Je me rends compte qu'il peut y avoir plus d'une façon de le faire, donc je recherche des directives de mise en œuvre spécifiques basées sur votre expérience.

J'ai mentionné dans l'un de mes commentaires à la réponse de Simoraman que j'avais pensé à deux façons de procéder. L'une de mes options était similaire à la suggestion de Jalayn de créer un projet en double et de générer une DLL, tandis que mon autre idée était de simplement créer un lien vers les fichiers du projet où il y avait du code que je voulais tester. Bien que les deux options puissent fonctionner, elles ne sont pas idéales.

Dans le second cas, j'aurais un gâchis de dépendances d'unité à gérer à moins que je puisse vraiment démêler l'architecture pour minimiser les dépendances. C'est bien pour les petits projets, mais les plus gros pourraient facilement devenir un vrai gâchis à gérer. Ma plus grande résistance à cette option est cependant sa pure inélégance. Bien sûr que je pourraispour le faire fonctionner, mais ce faisant, je dois effectivement interrompre l'encapsulation pour tester les composants internes d'un assemblage directement via la source, plutôt que de tester les via les interfaces publiques, ce qui, à mon avis, est un grand non-non. De même, avoir un fichier de projet supplémentaire signifierait soit la duplication des efforts dans deux projets à la fois, soit la recherche d'un moyen d'ajouter automatiquement les paramètres du fichier de projet à deux fichiers à la fois, ou de ne pas oublier de copier et renommer le champ de projet à chaque fois que je construis. Cela peut être automatisé sur le serveur de build peut-être, mais serait difficile à gérer dans l'IDE. Encore une fois, cela peut fonctionner, mais c'est un kludge au mieux, et une nuisance au pire si vous vous trompez.

La meilleure façon semble être de faire comme le nom de Whatsis commenté à ma question, et d'inclure simplement l'EXE comme référence dans le projet de test. Il s'avère qu'un EXE est effectivement traité de la même manière qu'une DLL dans ce cas, et je suis en mesure d'accéder à toutes mes classes joliment superposées pour tester tout ce qui flotte sur mon bateau.

Je pense que:

• Votre code de test d'entreprise doit être dans un projet distinct, testant votre bibliothèque de codes d'entreprise.
• Votre code de test GUI doit être dans un projet distinct, testant votre bibliothèque GUI. Maintenant, comment construire une bibliothèque GUI au lieu d'un exécutable, j'essaie d'y répondre plus tard.
• Si vous avez un my.namespace.biz.MyClass, votre classe de test doit être my.namespace.biz.MyClassTest (ou MyClassTestCase).
• Si vous souhaitez tester le code trouvé dans votre cible exécutable, vous devez avoir une configuration qui construit un EXE et une autre configuration qui construit une bibliothèque (DLL) qui est celle contre laquelle vous lancerez vos tests.

Ce sont les règles que j'aime suivre, que ce soit Java ou C # (sauf qu'il n'y a pas de problème EXE avec Java bien sûr :-))

Quant à la façon de configurer votre environnement de test, il me semble que vous avez au moins ces deux choix:

Utilisation de MSBuild

Créez un clone de votre fichier .proj (par exemple myproject-as-dll.proj ). Changez le OutputTypedans le fichier cloné de " EXE" en " Library". En utilisant la commande MSBuild, vous pouvez maintenant produire une bibliothèque que vous pouvez définir comme référence dans votre projet contenant des cas de test NUnit.

Cela me semble possible, mais je ne l'ai jamais utilisé aussi honnêtement, donc je ne suis pas sûr. De plus, vous n'avez peut-être pas MSBuild sur votre serveur de test d'intégration, et je ne sais pas s'il peut être séparé de Visual Studio ...

Utilisation de NAnt

Si vous n'êtes pas familier avec NAnt, vous devrez rechercher sur Google comment configurer vos builds de projet avec. Peut-être vérifiez -le , il est un peu ancien mais l'auteur a commenté les fichiers NAnt et si cela se passe d'explication ( Edit: en examinant son fichier plus en détail, je trouve son fichier de configuration extrêmement réutilisable ). Il fait également bien plus que simplement construire, car il exécute des cas de test et lance des outils de couverture de code. Maintenant, j'avoue que je n'ai jamais utilisé NAnt, contrairement à son homologue Java et père "Ant" que j'ai beaucoup utilisé mais je vois que c'est à peu près la même chose et je ne pense pas que ce soit difficile à apprendre.

Avec cet outil, vous pouvez proposer une configuration qui vous permettra de:

• construire tous vos projets (logique métier, GUI, etc.) dans des bibliothèques distinctes
• construisez vos projets de test
• lancer les tests (cette partie spécifique se fait avec la tâche NUnit2 ).
• examinez la couverture de votre code avec la tâche NCover .

Avec un peu plus de code, vous pourriez même:

• effectuer des déploiements nocturnes sur votre serveur d'intégration
• si NAnt est disponible sur votre serveur d'intégration, lancez des tests d'intégration nocturnes à l'aide de tâches planifiées

Tout se fait sans rien changer dans vos fichiers Visual Studio. Et, vraiment, cela ne ressemble pas à une ingénierie excessive, c'est juste un fichier. Cela peut vous prendre un, peut-être deux jours pour que tout fonctionne, mais vous aurez à mon avis une bonne configuration.

Enfin, je donnerais au client tout ce qui est nécessaire pour construire, tester et exécuter les projets. J'ai tendance à penser que cela montre votre professionnalisme et le fait que vous écrivez du code avec qualité dans votre esprit (ce qui me semble être le cas puisque vous recherchez des solutions élégantes)

Ce n'est pas parce que le projet est petit (au départ) que l'architecture appropriée est une ingénierie excessive. Le fait que vous vouliez écrire des tests indique que votre projet n'est pas un hack ponctuel complètement trivial.

Vous n'avez pas mentionné le cadre graphique que vous utilisez. WPF MVVM (Model-View-ViewModel) est bon et vous permet d'écrire des tests pour toute la logique assez facilement. Avec WinForms, j'ai entendu de bonnes choses à propos de MVP (Model-View-Presenter)

Jetez un œil à ma réponse à cette question: comment configurer MVP pour une solution Winforms?

J'ai en fait écrit un exemple d'application qui montre comment je couche et comment je teste mon interface graphique.

lire votre montage: utilisez un lanceur de test qui s'intègre à votre environnement de développement. J'utilise ReSharper.

J'avais écrit Nunit WinForms il y a quelques années (6 ans je suppose). Une chose dont je me souviens précisément, c'est que bien que ce soit un cas de test unitaire, il agit également comme un cas de test de bout en bout. Parfois, il n'y a pas grand-chose à tester sur un frontal (un formulaire simple). Ainsi, même si vous essayez de tester l'apparition d'une boîte de message sur un clic de bouton, vous testez involontairement diverses autres méthodes à partir d'autres couches. Il y a certaines choses que vous ne pouvez pas automatiser également. L'aspect, la convivialité et la convivialité ne peuvent pas être automatisés à l'aide de tests unitaires automatisés. Vous devrez exécuter des tests manuels avant de publier.