Autofixture: Problèmes d'intégration NCrunch et AutoFixture

Bonjour, je suis le développeur de NCrunch.

Je serais heureux de travailler avec vous pour trouver une solution à ce problème. Avec la conception actuelle, je n'ai malheureusement plus d'options pour résoudre le problème uniquement de mon côté du point d'intégration. Je pense que mon coureur n'est probablement pas le seul à avoir rencontré des problèmes avec la conception actuelle.

Comme vous l'avez probablement compris à travers les divers messages de documentation et de forum d'assistance que j'ai écrits, la racine du problème réside dans la génération aléatoire de paramètres de test par AutoFixture. Étant donné que les paramètres de test sont un élément essentiel pour identifier un test et l'exécuter par la suite, l'exécution sélective des tests devient impossible si les paramètres changent à chaque fois qu'un test est construit/découvert.

Le seul moyen fiable auquel je puisse penser pour résoudre ce problème serait de supprimer toute génération aléatoire de paramètres de test et d'utiliser à la place des valeurs fixes (c. De cette façon, les tests seraient toujours exactement les mêmes et ils pourraient être systématiquement les mêmes que n'importe quel autre test. Chaque utilisateur avec qui j'ai traité qui a utilisé AutoFixture pour la génération de paramètres l'a fait pour des paramètres dont ils ne se soucient pas aux fins de leurs tests, j'espère donc que cette approche n'aura pas de réel inconvénient aux yeux de l'utilisateur . Un avantage à cela est qu'il fonctionnerait également avec toutes les versions de NCrunch immédiatement et ne nécessiterait aucune modification du code de NCrunch ou de tout autre coureur.

@remcomoulder Merci beaucoup d'avoir participé ici - très apprécié ! J'ai un peu étudié cela et j'aimerais partager mes découvertes. Toutes mes découvertes ne s'appliquent qu'à xUnit .

TL DR : xUnit prend en charge de telles théories et NCrunch devrait également les prendre en charge pour xUnit. Pour NUnit - c'est une question ouverte et je n'ai pas encore enquêté là-dessus.

La fonctionnalité que nous utilisons semble être _légale_ pour xUnit. Nous avons notre propre TestDataDiscoverer qui indique que nos théories ne peuvent pas être pré-découvertes (car nous générons des données aléatoires). Plus tard, nous décorons notre AutoDataAttribute avec ce découvreur. xUnit respecte cet attribut et ne résout pas les valeurs des paramètres lors de la découverte.

Je pense que mon coureur n'est probablement pas le seul à avoir rencontré des problèmes avec la conception actuelle.

En fait, ce n'est pas vrai et R# et VS fonctionnent bien avec de telles théories. Ils permettent également de réexécuter la théorie particulière même si elle contient des données générées automatiquement. Je suggérerais de se concentrer sur VS car il contient également des phases de découverte et d'exécution et est open source.

Considérez le code de test suivant :

using Ploeh.AutoFixture.Xunit2;
using Xunit;

namespace Playground
{
    public class UnitTest
    {
        [Fact]
        public void StableTest()
        {
            Assert.True(true);
        }

        [Theory]
        [InlineData(1)]
        public void StableInlineTest(int value)
        {
            Assert.Equal(1, value);
        }

        [Theory, AutoData]
        public void VolatileTest(int value)
        {
            Assert.True(value % 2 == 0);
        }

        [Theory]
        [InlineAutoData(10)]
        [InlineAutoData(20)]
        [InlineAutoData(30)]
        public void VolatileTestWithInline(int value, int autoValue)
        {
            Assert.NotEqual(value, 40);
        }
    }
}

Projet de bibliothèque de tests .NET Framework. VS 2017.3. Cadre cible : 4.5.2. Paquets installés :

• xunit 2.2.0
• xunit.runner.visualstudio 2.2.0
• AutoFixture 3.50.6
• AutoFixture.Xunit2 3.50.6

Si vous déclenchez la découverte dans VS, vous verrez la sortie suivante :

Comme vous pouvez le remarquer, pour les théories qui prennent en charge la découverte de données ( StableInlineTest ), VS runner affiche les données réelles avec lesquelles le test sera exécuté ( 1 ). Pour les tests qui ne prennent pas en charge la découverte de données et contiennent des données générées automatiquement ( VolatileTest , VolatileTestWithInline ) VS ne découvre pas les cas théoriques et vous montre uniquement la théorie complète. Ce n'est qu'après avoir exécuté que vous pourrez voir les valeurs de cette invocation particulière :

Maintenant, vous pouvez réexécuter la théorie particulière et elle exécutera à nouveau _tous les cas théoriques_.

Comme vous pouvez le voir, il existe en fait un moyen de soutenir de telles théories et xUnit le fait parfaitement. NCrunch doit prendre en compte le fait que certains cas théoriques ne peuvent pas être pré-découverts. Pour de telles théories, vous devez réexécuter toute la théorie plutôt qu'un cas particulier. Je ne vois pas pourquoi ce n'est pas possible.

Le seul moyen fiable auquel je puisse penser pour résoudre ce problème serait de supprimer toute génération aléatoire de paramètres de test et d'utiliser à la place des valeurs fixes (c'est-à-dire des espaces réservés ou des consts) à la place

Actuellement, xUnit n'expose pas l'API pour modifier le nom d'affichage et remplacer les données générées par des espaces réservés. J'ai créé un problème pour eux (voir ici ), mais la réponse de Brad est que c'est irréel et ils suggèrent de simplement désactiver la découverte, ce que nous faisons déjà.

ou sinon limiter l'amorçage des valeurs de paramètre au cas de test lui-même.

Malheureusement, cela n'est actuellement pas possible pour notre produit et beaucoup de choses devraient être réécrites pour prendre en charge une seule graine.

Données des membres

Dans la documentation ici, vous avez un autre exemple (je l'ai réécrit en XUnit):

public class MemberDataSample
{
    public IEnumerable<object[]> GetData()
    {
        yield return new object[]
        {
            DateTime.Now
        };
    }

    [Theory, MemberData(nameof(GetData), DisableDiscoveryEnumeration = true)]
    public void DateTheory(DateTime dt)
    {
        Assert.True(DateTime.Now - dt < TimeSpan.FromMinutes(1));
    }
}

C'est tout à fait légal pour xUnit car il y a l'attribut DisableDiscoveryEnumeration . Cela fonctionne comme l'exemple ci-dessus - les cas théoriques ne sont pas pré-découverts.

La ligne de fond

Il semble que xUnit fournisse des instruments pour comprendre si le test est volatile ou non (au moyen d'un support d'énumération pré-découverte). Vous pouvez utiliser l'implémentation de VS comme exemple pour comprendre comment ils gèrent cela et faire de même dans votre produit. Probablement, ils utilisent simplement le SDK xUnit et leurs récepteurs de messages.

Étant donné que R# et VS prennent en charge de telles théories, cela me fait penser qu'en fait tout va bien avec notre produit.

En ce qui concerne la NUnit - discutons-en ensuite car je n'ai pas encore enquêté là-dessus. Probablement, nous n'avons pas une telle API pour cela.

Pourriez-vous s'il vous plaît partager votre opinion concernant la prise en charge de xUnit compte tenu de mes conclusions ? Ajouterez-vous un support pour
xUnit (arrêter de réexécuter tous les tests) et arrêter pour afficher cet avertissement d'incompatibilité ? ??

Il semble que je vous dois des excuses ici. Le cas d'utilisation que vous avez décrit ci-dessus fonctionne correctement sous NCrunch, pour les raisons que vous avez expliquées. Xunit évite la pré-énumération de la théorie et la réduit en un seul test où elle est identifiée et exécutée en toute sécurité. En testant cela maintenant, je peux confirmer que NCrunch le fait correctement. Il semble que nous n'ayons pas de problème évident avec InlineAutoData.

Je ne sais pas pourquoi cela a échoué pour moi plus tôt. Je suis actuellement incapable de créer moi-même un scénario dans lequel il échoue. Je sais que des utilisateurs m'ont dit qu'InlineAutoData ne fonctionnait pas, bien que je suppose qu'ils devront se manifester et fournir des exemples où c'est le cas.

J'aimerais attirer votre attention sur un cas d'utilisation spécifique qui, je le sais, brisera à la fois NCrunch et VS Runner. Je suppose que cela casserait également ReSharper et TD.NET, bien que je ne les ai pas testés car je ne les ai pas installés :

using Ploeh.AutoFixture;
using Ploeh.AutoFixture.Xunit2;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;

namespace XUnitAutoFixture
{
    public class TestFixture
    {
        private static readonly Fixture Fixture = new Fixture();

        public static IEnumerable<object[]> SomeTestData()
        {
            yield return new object[] { Fixture.Create<string>() };
            yield return new object[] { Fixture.Create<string>() };
        }

        [Theory, MemberData(nameof(SomeTestData))]
        public void Test(object value)
        {

        }
    }
}

Le code ci-dessus échouera dans tous les scénarios d'exécution sélective. Il réussira cependant si les tests sont découverts et exécutés dans la même étape. Ce scénario a été le catalyseur de l'avertissement donné par NCrunch à propos d'AutoFixture, car les utilisateurs le faisaient et demandaient de l'aide. Étant donné que je ne savais pas que AutoFixture désactivait la pré-énumération, j'avais supposé (à tort) que InlineAutoData était le même.

Mon hypothèse actuelle est que vous ne soutenez pas un tel scénario. Est-ce correct?

En testant cela maintenant, je peux confirmer que NCrunch le fait correctement.

C'est génial! Heureux d'apprendre qu'en fait xUnit est entièrement pris en charge par NCrunch 🎉 En ce qui concerne le NUnit - il a toujours été maladroit et nous devons enquêter sur ce que nous pouvons faire là-bas.

Cependant, j'observe toujours des problèmes avec NCrunch et AutoFixture. Actuellement, j'ai un projet xUnit avec AutoFixture et si je modifie ne serait-ce qu'une seule ligne, tous les tests sont réexécutés. Il semble que vous activez un tel comportement lorsque vous détectez AutoFixture pour vous assurer que rien n'est manqué.

Est-ce vrai? Si oui, pourriez-vous s'il vous plaît corriger cela pour désactiver un tel comportement pour xUnit car tout va bien là-bas ?

J'aimerais attirer votre attention sur un cas d'utilisation spécifique qui, je le sais, brisera à la fois NCrunch et VS Runner.
Mon hypothèse actuelle est que vous ne soutenez pas un tel scénario. Est-ce correct?

Oui, ce scénario brisera tous les coureurs. Cependant, comme cela a été correctement signalé quelque part sur votre forum, ce n'est pas à cause de l'AutoFixture, car vous pourriez écrire quelque chose comme ceci qui ne fonctionnera pas non plus :

public class TestFixture
{
    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { DateTime.Now.Ticks };
        yield return new object[] { DateTime.Now.Ticks };
    }

    [Theory, MemberData(nameof(SomeTestData))]
    public void Test(object value)
    {

    }
}

Pour un tel scénario, il est de votre responsabilité de désactiver manuellement la pré-découverte, afin qu'elle ressemble à ceci (faites attention à la propriété DisableDiscoveryEnumeration ) :

public class TestFixture
{
    private static readonly Fixture Fixture = new Fixture();

    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { Fixture.Create<string>() };
        yield return new object[] { Fixture.Create<string>() };
    }

    [Theory, MemberData(nameof(SomeTestData), DisableDiscoveryEnumeration = true)]
    public void Test(object value)
    {

    }
}

En fait, c'est censé être un scénario très rare car nous avons des attributs AutoData et InlineAutoData pour la génération de données. De plus, AutoFixture est simplement un outil et il est de la responsabilité du développeur de l'utiliser correctement.

Je ne déplacerais pas NCrunch dans un mode spécial simplement parce qu'il y a des gens qui peuvent utiliser l'outil de manière incorrecte. Le mieux que nous puissions faire ici est de mettre un problème connu quelque part pour décrire ce scénario particulier et de demander aux gens d'utiliser correctement xUnit (car ils pourraient ne pas le savoir).

Pourriez-vous s'il vous plaît confirmer que vous exécutez des tests d'une manière spéciale si vous détectez AutoFixture et si c'est le cas, pourriez-vous s'il vous plaît désactiver ce mode pour xUnit (pour NUnit, il est préférable de le garder tel quel). Il est également probable que cette page devrait également être mise à jour.

Pour le moment, NCrunch n'implémente aucune gestion spéciale pour AutoFixture en dehors de l'avertissement de compatibilité. Le comportement que vous avez rencontré est probablement dû au mode moteur que vous avez sélectionné. C'est entièrement configurable - si vous passez en mode "Exécuter les tests impactés automatiquement, les autres manuellement", je pense que vous verrez le moteur se comporter comme vous l'attendez.

Avec ce que j'ai appris de vous, je me sens prêt à supprimer complètement l'avertissement AutoFixture de NCrunch. J'avais déjà été convaincu par les utilisateurs de le reformuler, car il est devenu clair très tôt que l'avertissement était trop large et que certaines fonctionnalités d'AutoFixture fonctionnaient toujours correctement. Je pense que j'ai très mal compris comment AutoFixture est implémenté sous xunit.

Donc, je suppose que c'est probablement le meilleur scénario pour nous. Le cas d'utilisation qui m'a le plus cassé n'est de toute façon pas pris en charge techniquement, et tout le reste fonctionne bien. En attendant, je serai heureux d'essayer d'oublier mon propre embarras d'avoir testé et vérifié cela jusqu'à une conclusion incorrecte, si vous pouvez trouver des raisons de me pardonner l'avertissement de compatibilité trop zélé.

En attendant, je serai heureux d'essayer d'oublier mon propre embarras d'avoir testé et vérifié cela jusqu'à une conclusion incorrecte, si vous pouvez trouver des raisons de me pardonner l'avertissement de compatibilité trop zélé.

Pas de soucis! C'est tout à fait bien et nous sommes tous là pour nous aider à comprendre les choses C'est super que vous ayez suivi le ticket et nous en avons discuté - c'est trop

Avec ce que j'ai appris de vous, je me sens prêt à supprimer complètement l'avertissement AutoFixture de NCrunch.

Eh bien, nous avons toujours des problèmes avec NUnit (nous sommes cependant sur la bonne voie ), donc ce message semble être pertinent pour les projets NUnit. Il est probablement logique de désactiver cela pour xUnit uniquement, à moins que nous n'introduisions une prise en charge complète de la NUnit (ou au moins un moyen d'activer cette prise en charge).

J'ai encore une chose qui n'est pas claire pour moi. Qu'est-ce que cela signifie que vous ne prenez pas en charge, par exemple, AutoFixture et NUnit ? Oui, les noms des tests sont différents à chaque fois, mais est-ce important si vous réexécutez tous les tests (si le mode moteur est défini ainsi) ? Ou cela signifie-t-il que vous ne supportez pas davantage le moteur « Impacted only » pour eux ? Ma pensée était qu'au lieu de dire No support , il est probablement préférable de se limiter à certains scénarios particuliers que nous ne prenons pas en charge, tandis que les autres devraient convenir.

« Exécuter les tests concernés automatiquement, les autres manuellement »

Je n'ai pas pu trouver ce paramètre sur mon installation de 3.10.0.20 . Voulez-vous dire le paramètre Only consider tests 'Out of date' if they are 'Impacted' qui doit être défini sur true ? Désolé si j'ai raté ça quelque part - je suis un peu nouveau sur ce produit..

Mise à jour de la documentation

Il est probablement logique de ne pas _supprimer_ la casse avec xUnit et AutoFixture de cette page, mais plutôt de décrire comment l'utiliser correctement (utilisez l'attribut DisableDiscoveryEnumeration ). Il serait également intéressant de décrire l'exemple "NUnit Test Case With Inconsistent Name" pour xUnit et de demander à utiliser l'attribut DisableDiscoveryEnumeration avec MemberDataAttribute .

J'ai encore une chose qui n'est pas claire pour moi. Qu'est-ce que cela signifie que vous ne prenez pas en charge, par exemple, AutoFixture et NUnit ? Oui, les noms des tests sont différents à chaque fois, mais est-ce important si vous réexécutez tous les tests (si le mode moteur est défini ainsi) ? Ou cela signifie-t-il que vous ne supportez pas davantage le moteur « Impacted only » pour eux ? Ma pensée était qu'au lieu de dire Pas de support, il est probablement préférable de se limiter à certains scénarios particuliers que nous ne prenons pas en charge, tandis que les autres devraient convenir.

Cela est dû à la durée de vie du test sous NCrunch. NCrunch a un état important qui est attribué à chaque test (pensez résultat de réussite/échec, données de couverture de code, données de performance, sortie de trace, etc.). Ces données persistent tant que le test continue d'être « découvert » par le framework de test, même entre les sessions de VS. Lorsque le framework de test ne rapporte aucun test avec le même identifiant, le test est considéré comme terminé et tout l'état est détruit.

Lorsqu'un test est créé à l'aide de paramètres instables, chaque appel au framework de test pour découvrir les tests entraîne la création d'un tout nouveau test, car l'identifiant du test a changé. Le résultat est qu'à chaque fois que NCrunch appelle NUnit pour découvrir des tests (systématiquement après chaque build du projet de test), tout état détenu pour les tests avec des paramètres instables est rejeté. Alors c'est mauvais. Cela signifie que la détection d'impact ne fonctionnera pas et que le moteur effectue une tonne de travail supplémentaire en réexécutant des tests et en parcourant les résultats transitoires.

Le problème est cependant plus profond. Si le dumping de l'état du test était le seul problème réel, la gestion des tests instables pourrait toujours « fonctionner » dans le sens où ils seraient toujours exécutés par le moteur et les résultats seraient signalés. Les problèmes les plus profonds proviennent de la parallélisation, de l'exécution sélective et du traitement distribué de NCrunch.

Pour effectuer une exécution parallèle, NCrunch doit utiliser plusieurs processus de test qui exécutent des tests en parallèle. Les mécanismes de NUnit sont tels que les tests doivent être découverts avant de pouvoir être exécutés. Cela signifie qu'il doit y avoir toute une étape de découverte distincte exécutée à l'intérieur de chaque processus utilisé pour l'exécution, donc si nous avons deux processus, nous devons découvrir les tests deux fois. Si les tests ont des paramètres instables, chaque processus aura un ensemble de tests entièrement différent, ce qui empêchera le moteur de diviser la liste principale complète des tests entre les processus à exécuter. Ce problème est également étendu lors de l'utilisation du traitement distribué, car le processus d'exécution à distance s'exécute sur un matériel différent dans un environnement complètement différent.

Il y a aussi la question de l'exécution sélective. Le mode de fonctionnement par défaut de NCrunch consiste à toujours créer un nouveau processus de test lorsqu'il lui est spécifiquement demandé d'exécuter un test. Il s'agit d'effacer l'ardoise et d'être aussi cohérent que possible avec les autres coureurs. Une telle fonctionnalité ne peut pas fonctionner avec des paramètres instables, car générer un nouveau processus de test nécessite de redécouvrir des tests, qui par la suite ne peuvent pas être identifiés si leurs paramètres ont changé.

NUnit possède son propre système d'identification interne qui pourrait être utilisé pour identifier les tests avec des paramètres instables entre les processus, mais ce système d'identification est basé sur la séquence de génération de tests (c'est-à-dire qu'il est incrémentiel). Un tel système ne peut être utilisé par aucun lanceur de test qui doit gérer l'état du test sur plusieurs versions d'un assemblage de test, car si l'utilisateur crée un nouveau test, tous les identifiants ne seront plus dans l'ordre et les données deviendront dangereusement trompeuses. . Les développeurs de NUnit ont exprimé leur intérêt à s'éloigner de ce système basé sur des séquences et à adopter des identifiants générés à partir des attributs de test eux-mêmes, ce qui serait similaire à la façon dont Xunit le fait (et ne fonctionnerait probablement pas avec des paramètres instables).

Je pense toujours que la meilleure façon de résoudre ces problèmes est d'effectuer un amorçage cohérent des paramètres instables. Il existe toujours un concept selon lequel les tests doivent être reproductibles et cohérents, ce qui est difficile à réaliser si les tests randomisent entièrement toutes leurs entrées. Dans la pratique, un test qui génère des données amorcées de manière aléatoire pour son exécution est un tout nouveau test à chaque fois qu'il est généré, car le code peut se comporter différemment en fonction des données qui lui sont fournies.

Je n'ai pas pu trouver ce paramètre sur mon installation 3.10.0.20. Voulez-vous dire que le paramètre Ne considérer que les tests « Périmés » s'ils sont « Impactés » doit être défini sur vrai ? Désolé si j'ai raté ça quelque part - je suis un peu nouveau sur ce produit..

Allez dans le menu NCrunch, choisissez "Définir le mode moteur", et vous devriez y voir l'option. Si ce n'est pas le cas, il est possible que vous utilisiez une solution qui a été exécutée par une version beaucoup plus ancienne de NCrunch et qu'elle n'affiche que les modes de moteur hérités. Le simple fait de créer une nouvelle solution quelque part devrait résoudre ce problème.

@remcomoulder Ouah ! Merci pour cette explication si détaillée ! Maintenant, je vois qu'en effet, il est plus facile de dire que AutoFixture & NUnit ne sont pas actuellement pris en charge car il y a d'ÉNORMES problèmes sous le capot 😅

Je pense toujours que la meilleure façon de résoudre ces problèmes est d'effectuer un amorçage cohérent des paramètres instables.

En fait, dans ce PR, nous avons une idée un peu différente. Nous voulons modifier le nom du test pour qu'il soit stable. Par exemple, un test donné comme celui-ci :

    [Test, StableNameAutoData]
    public void Sample(int a, Data d1, DataWithToString d2, ISomeData d3)
    {
        Assert.IsTrue(true);
    }

le nom du test sera :

NUnit3RunnerTest709.TestNameTester.Sample(auto<System.Int32>,auto<NUnit3RunnerTest709.Data>,auto<NUnit3RunnerTest709.DataWithToString>,auto<Castle.Proxies.ISomeDataProxy>)

Le nom sera toujours le même lors de chaque découverte/exécution, tandis que les valeurs réelles des arguments différeront à chaque fois.

Compte tenu de votre connaissance approfondie de NUnit, comment évalueriez-vous cette approche ? ça va fonctionner pour vous? Je m'attends à ce que vous utilisiez un nom de théorie plutôt que de vous lier à des valeurs d'argument particulières. Par conséquent, si le nom du test est stable, vous ne devriez pas avoir de problèmes car il est désormais identifiable. Pourriez-vous s'il vous plaît confirmer avant de commencer à mettre en œuvre cela? ☺️

Il existe toujours un concept selon lequel les tests doivent être reproductibles et cohérents, ce qui est difficile à réaliser si les tests randomisent entièrement toutes leurs entrées.

Probablement, un jour nous prendrons en charge une graine stable afin que les tests puissent être rejoués avec les mêmes arguments, mais actuellement nous en sommes assez loin, donc ce n'est pas réaliste 😕 Au contraire, nous nous attendons à ce que les affirmations des utilisateurs soient suffisamment précises pour comprendre plus tard pourquoi le test a échoué même si l'entrée a été randomisée dans certaines plages.

Compte tenu de votre connaissance approfondie de NUnit, comment évalueriez-vous cette approche ? ça va fonctionner pour vous? Je m'attends à ce que vous utilisiez un nom de théorie plutôt que de vous lier à des valeurs d'argument particulières. Par conséquent, si le nom du test est stable, vous ne devriez pas avoir de problèmes car il est désormais identifiable. Pourriez-vous s'il vous plaît confirmer avant de commencer à mettre en œuvre cela? ☺️

Malheureusement, ma connaissance de NUnit est loin d'être approfondie :( NCrunch prend simplement le nom NUnit lui revient et l'utilise pour générer l'identifiant. Donc, en théorie, tant que votre solution a changé/stabilisé le nom physique du test comme renvoyé par l'API NUnit, alors nous devrions être OK ici
pour Ncrunch au moins.

Une chose à surveiller est le potentiel pour un utilisateur de créer plusieurs tests avec la même signature. Si les paramètres du nom sont réduits à des types bruts, cela devient beaucoup plus probable/possible. Tant que vous êtes au courant de ces scénarios, vous pouvez probablement coder une erreur ou quelque chose pour le décourager.

@remcomoulder Juste pour vous mettre à jour, afin que nous puissions enfin clore ce problème.

Comme cela a été discuté ci-dessus, le framework xUnit est pris en charge nativement. Cependant, pour NUnit, le problème n'était pas clair car il ne prend pas en charge les tests avec des noms volatiles.

Nous avons récemment fusionné un PR et publié une nouvelle version d'AutoFixture ( v3.51.0 ) qui ajoute la prise en charge des noms stables pour NUnit. Pour l'instant, les actions manuelles sont requises du côté de l'utilisateur (voir ici ), mais dans la v4, je vais le faire prêt à l'emploi.

Je viens de tester et de découvrir que si j'utilise l'approche ci-dessus, NCrunch ne peut exécuter que des tests modifiés et il semble que cela fonctionne désormais correctement. Je ne sais pas si certaines actions de votre part sont nécessaires (par exemple, documentez-les quelque part). Ce serait également bien de tester cette nouvelle fonctionnalité et de nous faire savoir si elle fonctionne bien maintenant, afin que nous puissions nous reposer 😄

@zvirja Merci de m'avoir mis en boucle à ce sujet. J'ai testé rapidement ce travail et il m'a l'air solide. En supprimant les éléments aléatoires des noms de test, le coureur peut systématiquement identifier les tests d'une session à l'autre et tout semble bien se passer :)

J'ai cependant une idée qui, je pense, pourrait nous faire gagner du temps dans l'assistance aux utilisateurs. Un problème que nous rencontrons tous avec les logiciels est que beaucoup de gens ne lisent pas les documents avant de prendre un outil. Il est utile de savoir que nous sommes désormais en mesure de les conseiller sur la façon de résoudre les problèmes de nom unique sous NUnit, mais la meilleure approche consiste toujours à résoudre le problème lui-même.

Je note que par défaut, AutoFixture utilisera le VolatileNameTestMethodBuilder. J'accepte que c'est pour des raisons de rétrocompatibilité et je suis d'accord que c'est raisonnable. Mais que se passe-t-il si nous permettons à cette valeur par défaut d'être remplacée à l'aide d'une variable d'environnement ? Si nous pouvions spécifier une variable d'environnement (disons, 'AutoFixture.FixedTestNames'=='1') pour forcer AutoFixture à utiliser VolatileNameTestMethodBuilder, il serait possible pour un exécuteur de spécifier le générateur à l'avance, sans que l'utilisateur n'ait besoin de faire quoi que ce soit. Ce serait également un bonus pour les personnes qui utilisent plusieurs coureurs, car elles pourraient implicitement utiliser différents constructeurs pour chaque coureur (sans aucun effort requis) et obtenir le meilleur des deux mondes.

Qu'est-ce que tu penses?

J'ai testé rapidement ce travail et il m'a l'air solide.

C'est génial! 🎉 Cela signifie que nous pouvons clore ce problème car maintenant tout fonctionne bien. Merci pour le test et votre participation ici

Qu'est-ce que tu penses?

Je pense que je me suis retrouvé avec une solution bien meilleure et plus simple - nous allons faire du FixedNameTestMethodBuilder une stratégie par défaut dans la v4 (notre prochaine version majeure) qui sortira dans un ou deux mois. Le PR approprié a déjà été approuvé , donc le code sera là. Par conséquent, nous travaillerons correctement et si quelqu'un a besoin de noms de test volatils, il s'y inscrire manuellement, comprenant clairement les conséquences.

Plus tard, nous pourrions faire quelque chose comme vous l'avez suggéré - ajouter une stratégie de commutation qui inspecte les variables d'environnement/AppConfig, mais je préfère le faire uniquement si cela est effectivement nécessaire.

Je pense que je me suis retrouvé avec une solution bien meilleure et plus simple - nous ferons de FixedNameTestMethodBuilder une stratégie par défaut dans la v4 (notre prochaine version majeure) qui sera publiée dans un ou deux mois.

Cela fonctionnera très bien pour moi :) Je suis heureux ! Merci pour tous vos efforts.

Cool Merci encore pour vos réponses et votre collaboration

Je ferme celui-ci car aucune action n'est requise des deux côtés.

@remcomulder @zvirja Je voulais juste dire que cette discussion (qui m'a aidé à comprendre un problème similaire), et le dévouement que vous avez démontré ici, n'est rien d'autre que génial ! Merci à vous deux pour vos excellents produits.