Autofixture: Problemas de integração NCrunch e AutoFixture

Olá, sou o desenvolvedor do NCrunch.

Terei prazer em trabalhar com você para encontrar uma solução para isso. Com o design atual, infelizmente estou sem opções para resolver o problema apenas do meu lado do ponto de integração. Acredito que meu corredor provavelmente não seja o único que teve problemas com o design atual.

Como você provavelmente entendeu por meio de várias postagens de documentação e fórum de suporte que escrevi, a raiz do problema está na geração aleatória de parâmetros de teste do AutoFixture. Como os parâmetros de teste são um elemento crítico na identificação de um teste e subsequentemente em sua execução, a execução seletiva de testes torna-se impossível se os parâmetros mudam toda vez que um teste é construído / descoberto.

A única maneira confiável que posso pensar para resolver esse problema seria remover toda a geração aleatória de parâmetros de teste e, em vez disso, usar valores fixos (ou seja, marcadores de posição ou consts), ou então limitar a propagação de valores de parâmetro para o próprio caso de teste. Desta forma, os testes seriam sempre exatamente os mesmos e poderiam ser consistentemente considerados iguais a qualquer outro teste. Todos os usuários com quem lidei que usaram AutoFixture para geração de parâmetros o fizeram para parâmetros com os quais eles não se "preocupam" para fins de teste, então espero que esta abordagem não tenha nenhuma desvantagem real aos olhos do usuário . Uma vantagem disso é que ele também funcionaria com todas as versões do NCrunch imediatamente e não exigiria nenhuma alteração de código no NCrunch ou em qualquer outro executor.

@remcomulder Muito obrigado por participar aqui - muito obrigado! Eu investiguei um pouco e gostaria de compartilhar minhas descobertas. Todas as minhas descobertas são aplicáveis apenas ao

TL DR: xUnit suporta tais teorias e NCrunch deve suportá-las para xUnit também. Para NUnit - essa é uma questão em aberto e eu não investiguei isso ainda.

O recurso que usamos parece ser _legal_ para xUnit. Temos nosso próprio TestDataDiscoverer que indica que nossas teorias não podem ser pré-descobertas (porque geramos dados aleatórios). Mais tarde, decoramos nosso AutoDataAttribute com este descobridor. O xUnit respeita este atributo e não resolve os valores dos parâmetros durante a descoberta.

Acredito que meu corredor provavelmente não seja o único que teve problemas com o design atual.

Na verdade, isso não é verdade e tanto R # quanto VS funcionam bem com essas teorias. Eles também permitem executar novamente a teoria específica, mesmo se ela contiver dados gerados automaticamente. Eu sugiro focar no VS, pois ele também contém fases de descoberta e execução e é de código aberto.

Considere o seguinte código de teste:

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);
        }
    }
}

Projeto de biblioteca de teste do .NET Framework. VS 2017.3. Estrutura de destino: 4.5.2. Pacotes instalados:

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

Se você acionar a descoberta no VS, verá a seguinte saída:

Como você pode notar, para as teorias que suportam a descoberta de dados ( StableInlineTest ), o VS runner mostra os dados reais com os quais o teste será executado ( 1 ). Para testes que não suportam descoberta de dados e contêm dados gerados automaticamente ( VolatileTest , VolatileTestWithInline ), o VS não descobre os casos de teoria e mostra apenas a teoria inteira. Somente depois de executar, você poderá ver os valores para esta invocação em particular:

Agora você pode executar novamente a teoria particular e ela executará _todos os casos de teoria_ novamente.

Como você pode ver, existe realmente uma maneira de apoiar essas teorias e o xUnit faz isso perfeitamente. O NCrunch deve levar em consideração o fato de que alguns casos teóricos não podem ser pré-descobertos. Para tais teorias, você precisa refazer toda a teoria, ao invés de um caso particular. Não vejo porque isso não é possível.

A única maneira confiável que consigo pensar para resolver esse problema seria remover toda a geração aleatória de parâmetros de teste e, em vez disso, usar valores fixos (ou seja, marcadores de posição ou consts).

Atualmente, o xUnit não expõe a API para alterar o nome de exibição e substituir os dados gerados por espaços reservados. Eu criei um problema para eles (veja aqui ), no entanto, a resposta de Brad é que isso é irreal e eles sugerem simplesmente desativar a descoberta, o que já estamos fazendo.

ou então limitar a propagação de valores de parâmetro para o caso de teste em si.

Infelizmente, isso não é possível para o nosso produto e muitas coisas devem ser reescritas para dar suporte a uma única semente.

Dados do membro

Na documentação aqui, você tem outro exemplo (eu o reescrevi para 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));
    }
}

É absolutamente legal para xUnit, pois há um atributo DisableDiscoveryEnumeration . Funciona como o exemplo acima - casos teóricos não estão sendo pré-descobertos.

O resultado final

Parece que o xUnit fornece instrumentos para entender se o teste é volátil ou não (por meio do suporte de enumeração pré-descoberta). Você pode usar a implementação do VS como um exemplo para entender como eles lidam com isso e fazem o mesmo em seu produto. Provavelmente, eles simplesmente usam o xUnit SDK e seus coletores de mensagens.

Dado que tanto R # quanto VS suportam tais teorias, isso me faz pensar que na verdade está tudo certo com nosso produto.

Quanto ao NUnit - vamos discutir isso depois, pois eu não investiguei ainda. Provavelmente, não temos essa API para isso.

Você poderia, por favor, compartilhar sua opinião sobre o suporte do xUnit de acordo com minhas descobertas? Você adicionará suporte para
xUnit (pare de executar novamente todos os testes) e pare para mostrar o aviso de incompatibilidade? 😉

Parece que devo a você um pedido de desculpas aqui. O caso de uso que você descreveu acima funciona corretamente no NCrunch, pelos motivos que você explicou. O Xunit está evitando a pré-enumeração da teoria e a está reduzindo em um único teste, onde é identificada e executada com segurança. Ao testar isso agora, posso confirmar que o NCrunch faz isso corretamente. Parece que não temos um problema óbvio com InlineAutoData.

Não sei por que isso falhou para mim antes. No momento, sou incapaz de criar um cenário em que isso falhe. Eu sei que alguns usuários me mencionaram que InlineAutoData não estava funcionando, embora eu ache que eles precisarão fornecer exemplos de onde é o caso.

Eu gostaria de chamar sua atenção para um caso de uso específico que estou ciente que quebrará o NCrunch e o VS Runner. Suponho que também interromperia o ReSharper e o TD.NET, embora não os tenha testado porque não os tenho instalados:

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)
        {

        }
    }
}

O código acima falhará em todos os cenários de execução seletiva. No entanto, ele será aprovado se os testes forem descobertos e executados na mesma etapa. Este cenário foi o catalisador por trás do aviso dado pelo NCrunch sobre o AutoFixture, já que os usuários estavam fazendo isso e pedindo suporte. Dado que eu não sabia sobre a desativação da pré-enumeração do AutoFixture, presumi (incorretamente) que InlineAutoData era o mesmo.

Minha suposição atual é que você não apóia tal cenário. Isso está correto?

Ao testar isso agora, posso confirmar que o NCrunch faz isso corretamente.

Isso é ótimo! Fico feliz em saber que, na verdade, o xUnit é totalmente suportado pelo NCrunch 🎉 Quanto ao NUnit - sempre foi desajeitado e precisamos investigar o que podemos fazer lá.

No entanto, ainda observo problemas com NCrunch e AutoFixture. Atualmente eu tenho o projeto xUnit com AutoFixture e se eu mudar até mesmo uma única linha, todos os testes são executados novamente. Parece que você ativa tal comportamento quando detecta a AutoFixtura para garantir que nada seja esquecido.

É assim mesmo? Se sim, você poderia corrigir isso para desabilitar tal comportamento para o xUnit, já que está tudo bem aí?

Eu gostaria de chamar sua atenção para um caso de uso específico que estou ciente que quebrará o NCrunch e o VS Runner.
Minha suposição atual é que você não apóia tal cenário. Isso está correto?

Sim, esse cenário vai quebrar todos os corredores. No entanto, como foi corretamente apontado em algum lugar do seu fórum, não é por causa da AutoFixtura, já que você pode escrever algo assim que também não funcionará:

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)
    {

    }
}

Para tal cenário, é sua responsabilidade desabilitar manualmente a pré-descoberta, para que fique assim (preste atenção à propriedade 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)
    {

    }
}

Na verdade, supõe-se que seja um cenário muito raro, pois temos os atributos AutoData e InlineAutoData para geração de dados. Além disso, a AutoFixture é simplesmente uma ferramenta e é responsabilidade do desenvolvedor usá-la corretamente.

Eu não mudaria o NCrunch para um modo especial simplesmente porque existem pessoas que podem usar a ferramenta incorretamente. O melhor que podemos fazer aqui é colocar um problema conhecido em algum lugar para descrever este cenário específico e pedir às pessoas que usem o xUnit corretamente (pois podem não saber disso).

Você poderia confirmar que executa os testes de uma maneira especial se detectar o AutoFixture e, em caso afirmativo, pode desativar esse modo para xUnit (para NUnit é melhor mantê-lo como está). Também é provável que esta página também deva ser atualizada.

No momento, o NCrunch não implementa nenhum tratamento especial para AutoFixture fora do aviso de compatibilidade. O comportamento que você experimentou provavelmente se deve ao modo de mecanismo que você selecionou. É totalmente configurável - se você alternar para o modo 'Executar testes impactados automaticamente, outros manualmente', acho que verá o mecanismo se comportar da maneira que você espera.

Com o que aprendi com você, me sinto pronto para remover totalmente o aviso de AutoFixtura do NCrunch. Eu já havia sido convencido pelos usuários a reformulá-lo, pois ficou claro muito cedo que o aviso era excessivamente amplo e alguns recursos do AutoFixture ainda estavam funcionando corretamente. Acho que entendi seriamente mal como o AutoFixture é implementado no xunit.

Portanto, acho que este é provavelmente o melhor cenário para nós. O caso de uso que mais me prejudicou não é tecnicamente suportado e todo o resto está funcionando bem. Enquanto isso, ficarei feliz em tentar esquecer meu próprio constrangimento por ter testado e verificado isso com uma conclusão incorreta, se você encontrar motivos para me perdoar pelo excesso de zelo aviso de compatibilidade.

Enquanto isso, ficarei feliz em tentar esquecer meu próprio constrangimento por ter testado e verificado isso com uma conclusão incorreta, se você encontrar motivos para me perdoar pelo excesso de zelo aviso de compatibilidade.

Sem problemas! Está tudo bem e estamos todos aqui para ajudar uns aos outros a entender as coisas 😅 Que bom que você acompanhou o tíquete e discutimos isso - é demais 🥇

Com o que aprendi com você, me sinto pronto para remover totalmente o aviso de AutoFixtura do NCrunch.

Bem, ainda temos problemas com o NUnit (estamos no caminho certo ), então esta mensagem parece ser relevante para projetos NUnit. Provavelmente, faz sentido desabilitá-lo apenas para xUnit, a menos que introduzamos o suporte completo para o NUnit (ou pelo menos uma forma de habilitar esse suporte).

Ainda tenho uma coisa que não está clara para mim. O que significa que você não oferece suporte, por exemplo, AutoFixture e NUnit? Sim, os nomes dos testes são diferentes para cada vez. No entanto, faz diferença se você executar novamente todos os testes (se o modo do mecanismo estiver definido assim)? Ou significa que você não oferece mais suporte ao mecanismo "Somente impactado" para eles? Meu pensamento era que em vez de dizer No support , provavelmente é melhor restringir a alguns cenários específicos que não suportamos, enquanto os restantes devem ser adequados.

'Executar testes impactados automaticamente, outros manualmente'

Não consegui encontrar essa configuração na minha instalação de 3.10.0.20 . Você quer dizer a configuração Only consider tests 'Out of date' if they are 'Impacted' que deve ser definida como true ? Desculpe se eu perdi isso em algum lugar - eu sou um pouco novo neste produto ..

Atualização de documentação

Provavelmente faz sentido não _remover_ o caso com xUnit e AutoFixture desta página, mas sim descrever como usá-lo corretamente (use o atributo DisableDiscoveryEnumeration ). Também seria legal descrever o exemplo "Caso de teste NUnit com nome inconsistente" para xUnit e pedir para usar o atributo DisableDiscoveryEnumeration junto com MemberDataAttribute .

Ainda tenho uma coisa que não está clara para mim. O que significa que você não oferece suporte, por exemplo, AutoFixture e NUnit? Sim, os nomes dos testes são diferentes para cada vez. No entanto, faz diferença se você executar novamente todos os testes (se o modo do mecanismo estiver definido assim)? Ou significa que você não oferece mais suporte ao mecanismo "Somente impactado" para eles? Meu pensamento era que, em vez de dizer Sem suporte, provavelmente é melhor restringir a alguns cenários específicos que não oferecemos suporte, enquanto os de descanso devem ser adequados.

Isso ocorre por causa da vida útil do teste sob NCrunch. NCrunch tem um estado importante que é atribuído a cada teste (pense em resultado aprovado / reprovado, dados de cobertura de código, dados de desempenho, saída de rastreamento, etc.). Esses dados persistem enquanto o teste continuar a ser 'descoberto' pela estrutura de teste, mesmo entre as sessões de VS. Quando a estrutura de teste não relata nenhum teste com o mesmo identificador, o teste é considerado encerrado e todo o estado é destruído.

Quando um teste é criado usando parâmetros instáveis, cada chamada na estrutura de teste para descobrir os resultados dos testes em um novo teste sendo criado, porque o identificador do teste foi alterado. O resultado é que toda vez que o NCrunch chama o NUnit para descobrir testes (consistentemente após cada construção do projeto de teste), todo o estado mantido para testes com parâmetros instáveis ​​é descartado. Então isso é ruim. Isso significa que a detecção de impacto não funcionará, e o mecanismo fará uma tonelada de trabalho extra executando testes e folheando resultados transitórios.

O problema é mais profundo. Se o despejo do estado de teste fosse o único problema real, o manuseio de testes instáveis ​​ainda poderia 'funcionar' no sentido de que eles ainda seriam executados pelo motor e os resultados seriam relatados. Os problemas mais profundos vêm da paralelização, da execução seletiva e do processamento distribuído do NCrunch.

Para realizar a execução paralela, o NCrunch precisa usar vários processos de teste que executam testes em paralelo. A mecânica do NUnit é tal que os testes devem ser descobertos antes de serem executados. Isso significa que deve haver uma etapa de descoberta separada inteira executada dentro de cada processo usado para execução, portanto, se tivermos dois processos, precisaremos descobrir os testes duas vezes. Se os testes tiverem parâmetros instáveis, cada processo terá um conjunto de testes totalmente diferente, tornando impossível para o mecanismo dividir a lista mestre completa de testes entre os processos para execução. Esse problema também é estendido ao usar o processamento distribuído, porque o processo de execução remota está sendo executado em um hardware diferente em um ambiente completamente diferente.

Há também a questão da execução seletiva. O modo de operação padrão do NCrunch é sempre criar um novo processo de teste quando é especificamente instruído a executar um teste. Isso é para limpar a lousa e ser o mais consistente possível com outros corredores. Tal recurso não pode funcionar com parâmetros instáveis, porque a geração de um novo processo de teste requer a redescoberta de testes, que posteriormente não podem ser identificados se seus parâmetros foram alterados.

O NUnit tem seu próprio sistema de ID interno que pode ser usado para identificar testes com parâmetros instáveis ​​entre processos, mas esse sistema de ID é baseado na sequência de geração de teste (ou seja, é incremental). Esse sistema não pode ser usado por qualquer executor de teste que precisa gerenciar o estado de teste em várias versões de um conjunto de teste, porque se o usuário criar um novo teste, todos os IDs sairão da sequência e os dados se tornarão perigosamente enganosos . Os desenvolvedores NUnit expressaram interesse em se afastar deste sistema baseado em sequência e em direção aos IDs gerados a partir dos próprios atributos de teste, que seriam semelhantes a como o Xunit faz (e provavelmente não funcionariam com parâmetros instáveis).

Ainda acredito que a melhor maneira de resolver esses problemas é realizar uma propagação consistente dos parâmetros instáveis. Sempre existe um conceito de que os testes devem ser repetíveis e consistentes, o que é difícil de conseguir se os testes estão randomizando totalmente todas as suas entradas. Na prática real, um teste que gera dados semeados aleatoriamente para sua execução é um teste totalmente novo toda vez que é gerado, pois o código pode se comportar de maneira diferente com base nos dados que é alimentado.

Não consegui encontrar essa configuração na minha instalação 3.10.0.20. Você quer dizer a configuração Considerar testes apenas 'Desatualizados' se eles estiverem 'Impactados' que deve ser definida como verdadeira? Desculpe se eu perdi isso em algum lugar - eu sou um pouco novo neste produto ..

Vá para o menu NCrunch, escolha 'Definir modo do motor' e você deverá ver a opção lá. Se não estiver lá, é possível que você esteja usando uma solução que foi executada por uma versão muito mais antiga do NCrunch e está mostrando apenas modos de mecanismo legados. Apenas criar uma nova solução em algum lugar deve resolver isso.

@remcomulder Uau! Obrigado por uma explicação tão detalhada! Agora eu vejo que de fato é mais fácil dizer que AutoFixture e NUnit não estão sendo suportados atualmente, pois existem alguns problemas ENORMES sob o capô 😅

Ainda acredito que a melhor maneira de resolver esses problemas é realizar uma propagação consistente dos parâmetros instáveis.

Na verdade, neste PR temos uma ideia um pouco diferente. Queremos alterar o nome do teste para que seja estável. Por exemplo, dado teste como este:

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

o nome do teste será:

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

O nome será sempre o mesmo durante cada descoberta / execução, enquanto os valores reais dos argumentos serão diferentes a cada vez.

Dado o seu profundo conhecimento do NUnit, como você avalia esta abordagem? Será que vai trabalhar para você? Espero que você use um nome de teoria, em vez de se vincular a valores de argumentos específicos. Portanto, se o nome do teste for estável, você não deverá ter problemas, pois agora ele é identificável. Você poderia confirmar antes de começarmos a implementar isso? ☺️

Sempre existe um conceito de que os testes devem ser repetíveis e consistentes, o que é difícil de conseguir se os testes estão randomizando totalmente todas as suas entradas.

Provavelmente, um dia ofereceremos suporte a uma semente estável para que os testes possam ser repetidos com os mesmos argumentos, no entanto, atualmente estamos muito longe disso, por isso não é realista 😕 Em vez disso, esperamos que as afirmações dos usuários sejam precisas o suficiente para entender mais tarde por que o teste falhou mesmo se a entrada foi randomizada em alguns intervalos.

Dado o seu profundo conhecimento do NUnit, como você avalia esta abordagem? Será que vai trabalhar para você? Espero que você use um nome de teoria, em vez de se vincular a valores de argumentos específicos. Portanto, se o nome do teste for estável, você não deverá ter problemas, pois agora ele é identificável. Você poderia confirmar antes de começarmos a implementar isso? ☺️

Infelizmente, meu conhecimento sobre NUnit está longe de ser profundo :( NCrunch basicamente usa o nome NUnit retorna para ele e usa isso para gerar o identificador. Portanto, em teoria, contanto que sua solução tenha alterado / estabilizado o nome físico do teste como retornado pela API NUnit, então devemos estar OK aqui
para NCrunch, pelo menos.

Algo a se observar é o potencial de um usuário criar vários testes com a mesma assinatura. Se os parâmetros no nome estão sendo reduzidos a tipos brutos, isso se torna muito mais provável / possível. Contanto que você esteja ciente desses cenários, provavelmente poderá codificar com um erro ou algo para desencorajá-lo.

@remcomulder Apenas para atualizá-lo, para que possamos finalmente encerrar este problema.

Como foi discutido acima, a estrutura xUnit está sendo suportada nativamente. No entanto, para o NUnit, o problema não estava claro, pois ele não oferece suporte a testes com nomes voláteis.

Recentemente, fundimos um PR e lançamos uma nova versão do AutoFixture ( v3.51.0 ) que adiciona suporte para nomes estáveis ​​para NUnit. Por enquanto, as ações manuais são necessárias do lado do usuário (veja aqui ), no entanto, na v4, vou torná-lo pronto para uso.

Acabei de testar e descobri que, se usar a abordagem acima, o NCrunch é capaz de executar apenas testes modificados e parece que agora funciona corretamente. Não tenho certeza se algumas ações de sua parte são necessárias (por exemplo, documente isso em algum lugar). Também seria bom se você testar esse novo recurso e nos informar se ele funciona bem agora, para que possamos descansar 😄

@zvirja Obrigado por me

No entanto, tenho uma ideia que acho que pode nos poupar algum tempo no suporte ao usuário. Um problema que todos encontramos com o software é que muitas pessoas não leem os documentos antes de escolherem uma ferramenta. É útil saber que agora podemos aconselhá-los sobre como resolver os problemas de nomes exclusivos em NUnit, mas a melhor abordagem é sempre fazer o problema se resolver sozinho.

Noto que, por padrão, o AutoFixture usará o VolatileNameTestMethodBuilder. Eu aceito isso por razões de compatibilidade com versões anteriores e concordo que isso é sensato. Mas e se permitíssemos que esse padrão fosse substituído por uma variável de ambiente? Se pudéssemos especificar uma variável de ambiente (digamos, 'AutoFixture.FixedTestNames' == '1') para forçar a AutoFixture a usar VolatileNameTestMethodBuilder, seria possível para um runner especificar o construtor antecipadamente, sem que o usuário precise fazer nada. Isso também seria um bônus para pessoas que usam vários corredores, já que podem usar implicitamente construtores diferentes para cada corredor (sem qualquer esforço necessário) e obter o melhor dos dois mundos.

O que você acha?

Fiz um teste rápido a este trabalho, e ele me parece sólido.

Fantástico! 🎉 O que significa que podemos encerrar este problema, pois agora tudo está funcionando bem. Obrigado pelo teste e sua participação aqui 🥇

O que você acha?

Acho que acabei com uma solução muito melhor e mais simples - faremos de FixedNameTestMethodBuilder uma estratégia padrão na v4 (nosso próximo grande lançamento), que será lançado em um ou dois meses. O PR apropriado já foi aprovado , então o código estará lá. Portanto, trabalharemos bem fora da caixa e se alguém precisar de nomes de teste voláteis - ele ativará manualmente, entendendo claramente as consequências.

Posteriormente, poderíamos fazer algo como você sugeriu - adicionar uma estratégia de troca que inspecione as variáveis ​​de ambiente / AppConfig; no entanto, prefiro fazer isso apenas se for realmente necessário.

Acho que acabei com uma solução muito melhor e mais simples - faremos do FixedNameTestMethodBuilder uma estratégia padrão na v4 (nosso próximo grande lançamento), que será lançado em um ou dois meses.

Isso vai funcionar muito bem para mim :) Estou feliz! Obrigado por todo o seu esforço.

Legal 😉 Obrigado novamente por suas respostas e colaboração 👍

Estou fechando este porque nenhuma ação é mais necessária de ambos os lados.

@remcomulder @zvirja Só queria dizer que esta discussão (que me ajudou a entender um problema semelhante) e a dedicação que você demonstrou aqui são impressionantes! Obrigado a ambos por seus excelentes produtos.