Nunit: appdomain per test (isolement par test), pour traiter les classes statiques

Je pense que ce serait une fonctionnalité intéressante ... nous pourrions avoir un attribut qui exécute soit un appareil entier, soit un cas de test individuel dans un domaine d'application séparé, selon l'endroit où il est placé. Cela pourrait être le début d'un tout nouvel ensemble d'options d'isolation.

C'est un élément assez important, mais si l'application référencée pouvait être une source d'idées, cela aiderait. Je ne pense pas que nous puissions l'utiliser comme source de code, car il s'agit d'une licence Apache 2.

Étant donné que les AppDomains ne sont pas une chose dans .NET Core, et qu'il y a en fait de bonnes raisons pour lesquelles, cela devrait être désactivé dans les versions .NET Core/.NET Standard du framework, sinon nous devrons fournir out-of-proc exécution par test. Out-of-proc est l'endroit où vous êtes censé aller maintenant si vous avez besoin de ce type d'isolement.

https://tldrlegal.com/license/apache-license-2.0- (apache-2.0)
https://tldrlegal.com/license/mit-license

Je ne sais rien à leur sujet, mais la seule restriction supplémentaire d'Apache 2 par rapport au MIT semble être que vous devez indiquer les modifications et si vous avez un fichier NOTICES, vous devez inclure leur notification.

Il y a deux façons de procéder.

1. Supposez que c'est OK si vous ne voyez aucune raison pour laquelle cela ne se produit pas.
2. Supposons que ce n'est pas acceptable à moins d'obtenir un avis juridique qualifié.

Comme vous pouvez probablement le deviner, je suis dans le camp 2. J'ai fait des recherches approfondies pour essayer de trouver un avocat spécialisé en propriété intellectuelle qui a publié quelque chose à ce sujet et j'ai échoué. Je pense avoir même demandé une fois à Rosen, sans obtenir de réponse.

Si l'approche "prenez simplement des idées" ne vous rend pas heureux, vous pouvez demander à l'auteur d'y contribuer. Cependant, dans ce cas, ce n'est pas sorcier, il est donc probablement plus facile de simplement réinventer. Nous savons certainement comment générer des domaines et des processus dans NUnit.

@jnm2 Sur la base de ceci: http://www.apache.org/foundation/license-faq.html#Distribute -changes Je dirais que nous pouvons utiliser un composant sous licence avec la licence Apache 2 à condition de franchir quelques étapes. Des cerceaux légèrement différents selon que nous modifions le code ou que nous l'utilisons tel quel. Pas de quoi s'inquiéter jusqu'à ce que cela se produise, je dirais.

@CharliePoole L'approche "juste prendre des idées" me rend en fait plus heureux de toute façon. J'étais juste intéressé parce que je pensais qu'Apache et le MIT étaient presque identiques, et nous sommes le MIT, et je pensais qu'une partie de l'idée était que les gens puissent simplement prendre du code s'ils le voulaient.

Chaque licence est différente. Le MIT vous permet de faire à peu près n'importe quoi. Apache vous permet de faire beaucoup de choses mais nécessite certaines choses de votre part, comme inclure la licence et les éventuels avis. Les entreprises demandent à quelqu'un d'examiner ces choses et de s'assurer qu'elles sont conformes. Nous avons toujours dû nous débrouiller avec des recherches et une aide juridique gratuite lorsqu'elle était disponible.

Au fil des ans, j'ai dû prendre moi-même des mesures contre un contrevenant à notre licence à quelques reprises. C'était notre licence précédente, qui exigeait que les avis soient conservés s'ils utilisaient le code. Avec le MIT, il n'y a que peu de choses qu'ils pourraient faire qui le violent et aucune d'entre elles n'est rentable. 😄

Nous devons donc décider si nous voulons implémenter l'isolement AppDomain et le conserver uniquement dans .NET Framework (Mono prend-il en charge AppDomain ?) ou implémenter l'isolement de processus et le faire fonctionner de la même manière partout. Nous pourrions finir par faire les deux aussi, bien qu'il semble plus simple de n'en faire qu'un que les deux.

Quoi qu'il en soit, je m'attends à ce que AppDomain-reuse ou process-reuse soit important pour les performances si vous avez beaucoup de cas de test individuels qui utilisent tous l'état statique.

(Ou si tout cela semble trop complexe, nous pourrions suivre la sagesse conventionnelle selon laquelle l'état statique est un anathème pour les tests et que les dépendances doivent être injectées.)

@jnm2 Ce problème demande une isolation __AppDomain__.

En suivant nos conventions, vous avez en fait déjà dit que nous le ferions, en ajoutant les étiquettes que vous avez ajoutées, mais ensuite votre commentaire dit que nous devons décider si nous le ferons. Si j'étais l'OP, je serais confus. :sourire: Mais là j'ai déjà dit ailleurs que nos étiquettes sont assez déroutantes !

L'incapacité à implémenter quelque chose sur chaque plate-forme ne nous a jamais empêché de faire quelque chose auparavant. Nous ne l'autorisons tout simplement pas sur les plates-formes où cela ne fonctionne pas. En fait, il y a beaucoup de choses avec AppDomains que nous ne faisons pas déjà sous .NET Standard. C'est juste un peu plus orienté vers l'utilisateur que d'autres choses.

Mon sentiment est que la mise en œuvre de l'isolation AppDomain conduira éventuellement à l'isolation des processus, mais nous n'avons pas à tout comprendre maintenant. C'est YAGNI. Idem pour la réutilisation. Comme vous, je suis sûr que nous en aurons envie à un moment donné, mais cela ressemble à une optimisation dont nous ne devrions pas nous soucier lors de la première implémentation d'une nouvelle fonctionnalité.

@CharliePoole Quelle étiquette communique que nous avons décidé de faire cela, l'étiquette pri: ?

Oui, avec le label is:enhancement plutôt que is:idea. Voir la page wiki sur les étiquettes.

Comme déjà dit, je suis arrivé à la conclusion que le système d'étiquettes que j'ai mis en place est acceptable pour nous une fois que nous nous y sommes habitués, mais ne dit pas grand-chose aux utilisateurs.

Si j'avais trié cela, je l'aurais marqué comme vous l'avez fait moins la conception et l'aurais ajouté à BackLog. Tout a besoin de design, mais l'étiquette signifie "ne codez pas avant de nous montrer un design". Si c'est à peu près ce qu'il dit - exécuter des tests dans un AppDomain séparé - c'est assez simple du point de vue de la conception, même s'il y a beaucoup de problèmes d'implémentation à résoudre. Cela signifierait que quelqu'un est libre de faire une communication publique.

J'ai lu les documents is: et j'ai vu An addition or improvement to an existing feature. mais rien ne suggère que l'équipe a décidé de faire la chose en cours de discussion.

design :

Certaines décisions de conception doivent être prises avant que cela puisse vraiment être travaillé. Parfois, cette étiquette peut être appliquée avant que quoi que ce soit ne se produise et d'autres fois, le travail peut avoir commencé mais atteint un point où les décisions de conception doivent être prises en impliquant d'autres membres de l'équipe.

Semble correspondre à un scénario où je demande à l'équipe de décider s'il vaut la peine d'ajouter une fonctionnalité AppDomain par rapport à une fonctionnalité hors procédure avant que quiconque n'écrive du code =) Je penche vers cette dernière. Une fois que vous et peut-être un autre membre de l'équipe répondez que cela vaut la peine de faire la fonctionnalité AppDomain, alors je m'attendrais à ce que l'étiquette soit supprimée et qu'une affectation ou une documentation pour up-for-grabs se produise.

Je ne m'attendrais pas non plus à ce qu'il aille dans le backlog si nous discutons toujours de savoir si nous voulons la fonctionnalité telle que décrite par rapport aux alternatives.

@dbones N'hésitez pas à plaider en faveur de plusieurs domaines d'application pour les cas de test par rapport à plusieurs processus pour les cas de test, si vous avez une opinion dans un sens ou dans l'autre.

@ jnm2 Arrêtons de discuter de méta-trucs ici et restons-en à la demande réelle ...

Vous avez demandé une discussion, je l'ai marqué pour discussion. Mon point de vue : cela semble être une bonne fonctionnalité que nous devrions ajouter au Backlog. Si vous programmez et testez une application qui s'exécute sur une plate-forme avec AppDomains, vous devriez pouvoir créer un domaine d'application pour vos tests si nécessaire. Je verrais cela comme utilisé soit sur un luminaire ou un test.

Il est possible que nous ayons besoin d'exécuter une configuration et un démontage de niveau supérieur, y compris l'instanciation de l'appareil, dans le domaine de l'application également. Lorsqu'il est utilisé sur une méthode, cela peut signifier que OneTimeSetUp est exécuté deux fois. IOW, cela nécessite en fait de modifier le cycle de vie de l'appareil.

Si nous décidons plus tard d'implémenter l'exécution dans un processus, nous aurons besoin de tout ce que nous faisons pour les domaines d'application et d'autres choses, donc faire des domaines d'application semble être un bon début.

Cela devrait être fait par quelqu'un avec une compréhension assez profonde des entrailles de NUnit. 😄

@jnm2 , cela ne me dérange pas, l'un ou l'autre devrait fonctionner. ( @both , veuillez ne pas implémenter quoi que ce soit qui, selon vous, affectera votre chemin de mise à niveau)

mon objectif principal est d'exécuter du code dans un isolement complet et de l'invoquer via son API (considérez un test de contrat/api sur un petit service, où le service exécute toute sa pile, sans moquerie, dans l'appdomain/processus), lorsque le test est fait puis détruisez l'instance de service, et cela devrait détruire toutes les dépendances (qui ont des classes statiques).

Personnellement, je suis un peu mal à l'aise avec l'idée de créer un AppDomain pour chaque test ou même d'exécuter chaque test dans son propre processus. Ajouter cette quantité de complexité au cadre pour prendre en charge un cas d'utilisation très limité est au-dessus de la ligne IMHO. Je serais peut-être d'accord avec l'idée si cela pouvait être limité à un attribut appliqué aux appareils de test ou aux tests, mais si les changements commençaient à se répandre dans le reste du cadre, je serais contre l'idée.

Si quelqu'un voulait tracer comment nous pourrions faire cela sans ajouter trop de complexité, alors je pourrais être convaincu du contraire.

J'ai supposé qu'il ne s'agissait que d'un attribut que vous appliquez lorsque vous en avez besoin.

J'ai supposé qu'il ne s'agissait que d'un attribut que vous appliquez lorsque vous en avez besoin.

Si tel est le cas, je serais d'accord avec l'amélioration. J'ai immédiatement pensé à nos différentes options de ligne de commande qui auraient pu colorer mon attitude.

L'attribut devrait être capable d'intercepter les appels de méthode au test et à la configuration et au démontage, de mettre en place un nouveau processus ou AppDomain, et d'être capable d'examiner les commandes interceptées, de les sérialiser et de les comprendre suffisamment bien pour les exécuter manuellement sur l'autre côté. D'après le travail AppDomain que j'ai effectué, cela ira assez loin dans le système de commande de test.

Il n'y a aucune garantie que les paramètres seront même sérialisables.

Il ne fait aucun doute que c'est une mise en œuvre difficile. Les tests paramétrés présentent un problème supplémentaire, qui pourrait suggérer que l'implémenteur adopte une approche incrémentielle :

1. Essais simples
2. Tests paramétrés avec TestCase
3. TestCaseSource utilisant des champs
4. TestCaseSource utilisant des propriétés et des méthodes (c'est là que se pose le problème de sérialisation)

Je serais prêt à prendre des relations publiques distinctes pour chaque étape, mais nous devrons décider si nous publierions avec cela ne fonctionnant que dans certains cas.

Ironiquement, ce serait plus facile pour nos cas de test "dynamiques" hypothétiques, dont nous parlons depuis longtemps... tout serait fait au moment de l'exécution dans le domaine isolé.

Je préférerais trouver un exemple de code de contournement permettant aux gens d'appeler manuellement IsolationUtils.RunNewProcess(() => { }) ou IsolationUtils.RunNewAppDomain(() => { }) (j'ai un tel code qui traîne) plutôt que de donner la priorité à cette fonctionnalité par rapport à d'autres corrections de bogues hi-pri. Cela place le fardeau de la configuration, du démontage, du paramétrage, etc. sur l'utilisateur final pour le moment. Une seule personne l'a demandé.

Autrement dit, à moins que ce ne soit votre truc et que vous ayez un désir particulièrement ardent de le mettre en œuvre. :+1:

@ jnm2 Eh bien, vous l'avez priorisé vous-même comme d'habitude, il n'est donc pas prioritaire par rapport aux corrections de bogues hautement prioritaires.

Quant à IsolationUtils , c'est une autre option à coup sûr. Je verrais cela comme une autre idée de problème moi-même.

À mon avis, le but du triage est de permettre à quelqu'un de travailler sur quelque chose et de savoir que nous l'accepterons si le code est propre et réussit les tests. Nous n'assignons jamais de travail à qui que ce soit, nous ne décidons donc pas ici de ce qui doit être fait en premier . Individuellement, l'un de nous peut décider de le faire, bien sûr.

Nous pouvons aussi décider que nous n'accepterons jamais ce changement, peu importe qui l'a fait, aussi bien écrit soit-il. C'est en fait une courtoisie envers les utilisateurs afin qu'ils ne perdent pas de temps. Donc, si c'est ce que vous dites, alors vous êtes sur le point ici, même si je ne suis pas d'accord avec vous.

Je sais que cela est revenu à plusieurs reprises au fil des ans et nous avons toujours dit "pas encore".

Tout ce que je dis, c'est que je ne pense pas que l'équipe du framework devrait se sentir _obligatoire_ de donner la priorité à cela car nous avons l'option d'exemple de code afin que personne ne soit bloqué et que la demande soit faible. Je serais heureux d'accepter un changement pour ajouter un processus par cas de test si quelqu'un de la communauté devait y travailler. (En raison du niveau de complexité, je ne suis pas sûr que cela vaille la peine d'être documenté au point où nous pourrions appliquer up-for-grabs .)

Je ne sais pas si nous devrions accepter une contribution vers AppDomain-per-test-case parce que la demande d'AppDomain par rapport à out-of-proc est nulle que j'ai vu, et finalement les gens _voudront_ out-of-proc s'ils veulent soit maintenant.

Je suis désolé de harceler, mais je pense qu'il est important d'avoir un terrain d'entente sur ce que signifie trier une demande. L'étiquette "up-for-grabs" n'a pas d'importance. Soit nous pensons que quelque chose est une caractéristique acceptable, soit nous ne le pensons pas. Il n'y a pas de "Ce n'est vraiment pas acceptable mais si vous faites le travail nous le considérerons."

La décision binaire d'acceptabilité est effectuée en l'attribuant en tant que fonctionnalité (ou amélioration) ou en la fermant en tant que wontfix. Point final. Soit vous détestez suffisamment cette idée, soit vous la rejetez totalement, soit vous ne la détestez pas.

Si nous l'acceptons, il peut être priorisé, avoir des étiquettes supplémentaires ajoutées, etc.

Il y a une frontière entre faire des suggestions sur des solutions alternatives à un problème et dire aux utilisateurs ce qu'ils devraient vouloir. Beaucoup de nos utilisateurs travaillent dans des entreprises qui sont __way__ derrière la courbe d'adoption de la technologie. Les gens voudront utiliser AppDomains pendant de nombreuses années, que nous pensions qu'ils le devraient ou non.

:+1: En réaffirmant plus clairement :
D'après ce que je peux voir maintenant, je pense que le processus par cas de test est une fonctionnalité acceptable pri:normal .
Je doute que AppDomain-per-test-case soit une bonne direction, donc je suis inclus pour dire que ce n'est pas une fonctionnalité acceptable à moins qu'il y ait une raison pour laquelle nous ne pouvons pas faire la solution plus large et sans doute plus propre du processus par test -Cas.

Il est temps de prendre du recul et de laisser les autres s'exprimer. 😳

Je pense que nous devons faire attention à ce que nous acceptons comme fonctionnalités dans le cadre. La plupart des utilisateurs, comme @dbones , ont des cas d'utilisation très valables et c'est une idée intéressante, mais je pense que c'est la première fois que je vois cette demande depuis plusieurs années et je doute qu'elle soit largement utilisée.

À mon humble avis, nous avons déjà beaucoup trop d'options de ligne de commande, dont la majorité ne sont jamais utilisées. De même, nous avons des dizaines de fonctionnalités qui semblaient cool à l'époque mais qui ne sont jamais utilisées. Je voudrais arrêter ce fluage de fonctionnalité et évaluer chaque amélioration pour sa valeur et son utilisation. Toutes ces options supplémentaires rendent plus difficile pour les utilisateurs de trouver ce dont ils ont vraiment besoin.

J'aimerais que nous puissions ajouter quelque chose comme App Analytics à NUnit pour suivre exactement quelles fonctionnalités sont utilisées et sur quels frameworks 😄

Si vous voulez éviter le fluage, c'est un bon point de départ. :le sourire:

Je dirai que j'ai vu beaucoup d'utilisateurs créer des AppDomains et demander parfois s'il existe un moyen pour NUnit de le faire pour eux.

@ jnm2 En ce qui concerne l'exemple de code que vous avez mentionné en utilisant IsolationUtils, serait-il possible de l'obtenir.

@psandhu79 Pour un domaine d'application distinct, voici le code :

public static class IsolationUtils
{
    public static void RunInNewAppDomain(Action action)
    {
        if (action == null) throw new ArgumentNullException(nameof(action));

        var friendlyName = $"{typeof(IsolationUtils).Name}.{nameof(RunInNewAppDomain)}({action.Method})";
        var domain = AppDomain.CreateDomain(friendlyName, null, AppDomain.CurrentDomain.SetupInformation);
        try
        {
            domain.DoCallBack(action.Invoke);
        }
        finally
        {
            AppDomain.Unload(domain);
        }
    }

    public static T RunInNewAppDomain<T>(Func<T> func)
    {
        if (func == null) throw new ArgumentNullException(nameof(func));

        var friendlyName = $"{typeof(IsolationUtils).Name}.{nameof(RunInNewAppDomain)}({func.Method})";
        var domain = AppDomain.CreateDomain(friendlyName, null, AppDomain.CurrentDomain.SetupInformation);
        try
        {
            var invoker = (CrossDomainInvoker)domain.CreateInstanceAndUnwrap(typeof(CrossDomainInvoker).Assembly.FullName, typeof(CrossDomainInvoker).FullName);
            return invoker.Invoke(func);
        }
        finally
        {
            AppDomain.Unload(domain);
        }
    }

    private sealed class CrossDomainInvoker : MarshalByRefObject
    {
        public T Invoke<T>(Func<T> func) => func.Invoke();
    }
}

Une chose à laquelle il faut faire attention est de ne pas passer de lambdas ou de fonctions locales qui capturent des variables ou des paramètres locaux, car le compilateur créera une classe de fermeture générée automatiquement pour ce qui ne sera pas sérialisable. Il est assez simple d'écrire manuellement une classe de fermeture sérialisable. (Remarque, pas MarshalByRefObject mais [Serializable] . Sinon, vous reviendrez à l'exécution dans l'assembly d'origine.)

Il n'est pas possible de créer un NewAppDomainAttribute à appliquer au test et de faire en sorte que l'installation et le démontage s'exécutent également dans cet autre AppDomain. D'après le test que j'ai effectué, la seule chose qui retient cela est que chaque type dérivant de TestCommand , y compris tous les types tiers impliqués, devrait être sérialisable.

L'exécution dans un processus séparé est un peu plus complexe (émission d'un assemblage) mais je peux également le partager si cela vous intéresse.

Hé, découvrez cette bibliothèque sympa de @zastrowm ! https://bitbucket.org/zastrowm/nunit.applicationdomain

La bibliothèque NUnit.ApplicationDomain fonctionne en utilisant TestActionAttribute pour exécuter la méthode de test avant l'exécution du test "normal" dans le domaine d'application par défaut. Cette exécution est effectuée en utilisant ces étapes :

1. Rassemblez les arguments de la méthode NUnit actuelle (elle peut utiliser la réflexion pour cela)
2. Créer un domaine d'application
3. (dans le domaine de l'application) Construire une nouvelle instance de la classe de test
4. (dans le domaine de l'application) Appelez les méthodes SetUp (découvertes par réflexion)
5. (dans le domaine de l'application) Appelez le test avec des copies des arguments précédemment enregistrés
6. (dans le domaine de l'application) Invoquer les méthodes Teardown (découvert par réflexion)
7. (dans le domaine de l'application) Capturez le résultat du test ou l'exception qui s'est produite
8. Disposer du domaine
9. Lancer une exception indiquant le succès ou l'échec (contournant ainsi l'exécution normale du test)

C'est un peu hacky, car il n'utilise aucune infrastructure NUnit pour exécuter le test - je ne suis pas sûr que lorsque j'ai créé la bibliothèque, une telle infrastructure existait - mais cela permet d'exécuter des UT dans un domaine d'application.

Je ne sais pas si cela aide réellement quelqu'un, mais j'ai pensé que je viendrais l'expliquer, puisque mon nom a été abandonné :: )

C'est le genre de chose où je n'ai pas vraiment envie d'implémenter appdomain-per-test-case, mais j'irais jusqu'au bout pour m'assurer que nous fournissons les bons points d'extensibilité pour que les bibliothèques comme NUnit.ApplicationDomain ne soient pas t intrinsèquement des solutions de contournement.

Avons-nous prévu de travailler sur cette fonctionnalité ?

Juste pour jeter un scénario réel dans le mélange : nous avons un client qui a une grande base de code qui dépend fortement des classes statiques avec des caches et des états statiques. Leur exécution de tests unitaires est catastrophique, car ils doivent effacer manuellement toutes les données pertinentes après chaque test dans chaque assemblage de test, et parfois cela est oublié et ils doivent à nouveau examiner quelles données doivent être réellement effacées et modifier les tests assez souvent . De plus, les tests ne peuvent pas être exécutés en parallèle et les tests en série prennent des heures.

L'idée était maintenant : Refactoriser le code pour ne plus utiliser de statique. Ce serait une entreprise énorme car, comme je l'ai dit, la base de code est très grande et l'impact est très élevé (retest complet, réécriture des chemins de code critiques pour s'adapter au fait que la statique "n'est plus là") . Le refactoring est en soi une bonne idée, mais il faudrait qu'il se fasse par étapes plus petites et soigneusement planifié.

Les tests, cependant, prendraient encore des heures jusqu'à ce que toute la restructuration soit prête.

Une solution à court terme au problème serait d'avoir des AppDomains par TEST. Juste pour clarifier : le code restera probablement sur .NET Framework complet et le matériel sera "buffé" pour atténuer la demande accrue de CPU/mémoire, donc nous serions d'accord avec cela.

Même si cela n'est pas implémenté officiellement, j'ai vraiment tendance à l'implémenter de la manière hacky @zastrowm suggérée pour notre projet (ou utiliser NUnit.ApplicationDomain directement).

Cela doit être vraiment déroutant pour les utilisateurs que ce problème...

1. A été autour depuis si longtemps
2. Est étiqueté comme une fonctionnalité acceptée (c'est-à-dire pas une idée)
3. Est étiqueté comme nécessitant des travaux de conception
4. A des commentaires de divers membres de l'équipe qui
   4.1 Privilégier la fonctionnalité
   4.2 Sont opposés à la fonctionnalité
   4.3 Vous souhaitez rendre possible l'implémentation de la fonctionnalité par des crochets d'extensibilité
5. N'a jamais été attribué à personne

Je ne pense pas que le fait que certaines plates-formes n'aient pas d'AppDomains ne signifie pas que nous ne pouvons pas avoir la fonctionnalité. Il devrait évidemment être limité aux plates-formes qui en disposent, tout comme nous l'avons fait avec l'option console qui permet de décider du nombre d'AppDomains à utiliser.

@jnm2 vient juste de dire merci pour la classe util, cela m'a aidé à résoudre un problème avec AppContext provoquant l'échec des tests ultérieurs en fonction de la première fois que la valeur a été définie. Merci d'avoir fourni le code et une bonne explication sur la façon de l'utiliser ! 🎉

Je remets cela à idea car il n'est pas accepté. Personnellement, je ne suis pas favorable à l'ajout d'une nouvelle fonctionnalité AppDomain car elle ne s'applique désormais qu'à .NET 4.5. Si nous implémentons l'isolation des processus comme dans #3378, nous aurons alors une alternative qui fonctionne sur toutes les plateformes.

À cause de cela, je penche pour la fermeture. Des objections @nunit/framework-team ?

je penche aussi pour la fermeture