Je semble avoir un problème, l'application que nous utilisons utilise un noyau Ninject et contient une configuration particulière recueillie avec le contenu de l'appel WCF (nom d'utilisateur, jeton ...).
Sur la base d'une configuration particulière, l'utilisateur est attribué des droits sur l'application, il est blindé via une instance particulière dans le noyau Ninject.
Nous ne pouvons pas simplement recomposer le noyau Ninject, ce que nous aimerions faire est de faire fonctionner quelques tests de Nunit, mais courez chacun d'eux dans un domaine d'application séparé (recréant le noyau à chaque fois avec des paramètres différents).
Je n'ai trouvé que des moyens de gérer des projets de test entiers dans différents domaines d'applications, mais pas de test par test.
Y a-t-il un moyen de résoudre ce problème?
Malheureusement, la configuration Ninject n'est pas de notre côté, nous devons «vivre» de cette façon.
3 Réponses :
Je ne pense pas qu'il y ait un moyen de résoudre sans ré-écriture de pièces du code Nunit. Cela a été un moment depuis que j'ai été à l'intérieur du code Nunit, mais je suis à peu près sûr que la pièce de chargement de domaine d'application principale n'a pas changé.
Nunit utilise généralement deux domaines d'application. La valeur par défaut qui est créée lorsque Nunit est exécutée et une version séparée pour charger les ensembles de test et les assemblages auxquels ils font référence. C'est la principale raison pour que cela consiste à permettre le déchargement des assemblages de test. Vous ne pouvez pas décharger une DLL, mais vous pouvez décharger une appdomaine.
Vous pourriez être capable d'exécuter une nouvelle fois une fois par test et passez le test sur la ligne de commande, mais c'est moche et je ne suis pas sûr que cela aidera.
Il pourrait également être possible de tirer parti de Attributs d'action dans Nunit 2.6 , mais vous allez faire beaucoup de travail là-bas pour le faire.
Vous pourriez également être en mesure de créer un nouveau domaine d'application dans votre méthode de configuration et de l'appeler dans chaque test. Maladroit mais possible.
Je suis désolé de ne pas avoir une réponse plus complète.
Je ne suis pas tout à fait sûr de votre question. Cependant, il semble que vous ayez besoin d'une sorte de mise en œuvre personnalisée. Avez-vous envisagé des attributs de test personnalisés? Ensuite, peut-on configurer chaque attribut pour exécuter dans un domaine d'application différent? Je fais juste en train de tourner quelques idées, mais il peut y avoir de meilleurs moyens de faire cela.
J'ai besoin de faire exactement la même chose, alors j'ai créé une bibliothèque qui prend essentiellement le test actuel et la réécute dans une nouvelle Appdomain. C'est un package Nuget appelé Nunit.ApplicationDomaine et est Open Source .
Exemple code:
Toute solution pour le noyau .NET?
Non, pas en ce moment. La seule chose que je peux penser est un autre processus, mais c'est vraiment lourd