Autofixture: Problemas de integración de NCrunch y AutoFixture

Hola, soy el desarrollador de NCrunch.

Estaré encantado de trabajar contigo para encontrar una solución a esto. Con el diseño actual, lamentablemente no tengo opciones para resolver el problema únicamente en mi lado del punto de integración. Creo que mi corredor probablemente no sea el único que ha tenido problemas con el diseño actual.

Como probablemente haya entendido a través de la documentación y las publicaciones del foro de soporte que he escrito, la raíz del problema radica en la generación aleatoria de parámetros de prueba de AutoFixture. Debido a que los parámetros de prueba son un elemento crítico para identificar una prueba y posteriormente ejecutarla, la ejecución selectiva de pruebas se vuelve imposible si los parámetros cambian cada vez que se construye / descubre una prueba.

La única forma confiable en la que puedo pensar para resolver este problema sería eliminar toda la generación aleatoria de parámetros de prueba y, en su lugar, usar valores fijos (es decir, marcadores de posición o consts), o limitar la siembra de valores de parámetros al caso de prueba en sí. De esta manera, las pruebas siempre serían exactamente las mismas y se podrían encontrar consistentemente iguales a cualquier otra prueba. Todos los usuarios con los que he tratado que han usado AutoFixture para la generación de parámetros lo han hecho para los parámetros que no 'les importan' para los propósitos de sus pruebas, por lo que espero que este enfoque no tenga ningún inconveniente real a los ojos del usuario. . Un beneficio de esto es que también funcionaría con todas las versiones de NCrunch inmediatamente y no requeriría ningún cambio de código en NCrunch o cualquier otro corredor.

@remcomulder Muchas gracias por participar aquí, ¡muy apreciado! Lo he investigado un poco y me gustaría compartir mis hallazgos. Todos mis hallazgos son aplicables solo a

TL DR: xUnit admite estas teorías y NCrunch también debería admitirlas para xUnit. Para NUnit, esa es una pregunta abierta y aún no lo he investigado.

La función que usamos parece ser _legal_ para xUnit. Tenemos nuestro propio TestDataDiscoverer que indica que nuestras teorías no pueden ser descubiertas previamente (porque generamos datos aleatorios). Posteriormente decoramos nuestro AutoDataAttribute con este descubridor. xUnit respeta este atributo y no resuelve los valores de los parámetros durante el descubrimiento.

Creo que mi corredor probablemente no sea el único que ha tenido problemas con el diseño actual.

En realidad, eso no es cierto y tanto R # como VS funcionan bien con tales teorías. También permiten volver a ejecutar la teoría particular incluso si contiene datos generados automáticamente. Sugeriría centrarse en VS, ya que también contiene fases de descubrimiento y ejecución y es de código abierto.

Considere el siguiente código de prueba:

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

Proyecto de biblioteca de prueba de .NET Framework. VS 2017.3. Marco objetivo: 4.5.2. Paquetes instalados:

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

Si activa descubrir en VS, verá el siguiente resultado:

Como puede notar, para las teorías que apoyan el descubrimiento de datos ( StableInlineTest ), VS runner muestra los datos reales con los que se ejecutará la prueba ( 1 ). Para las pruebas que no admiten el descubrimiento de datos y contienen datos generados automáticamente ( VolatileTest , VolatileTestWithInline ), VS no descubre los casos teóricos y le muestra solo la teoría completa. Solo después de ejecutar, podrá ver los valores para esta invocación en particular:

Ahora puede volver a ejecutar la teoría particular y se ejecutará _todos los casos de teoría_ nuevamente.

Como puede ver, en realidad hay una manera de respaldar tales teorías y xUnit lo hace perfectamente. NCrunch debe tener en cuenta el hecho de que algunos casos teóricos no se pueden descubrir previamente. Para tales teorías, debe volver a ejecutar la teoría completa, en lugar de un caso particular. No veo por qué eso no es posible.

La única forma confiable en la que puedo pensar para resolver este problema sería eliminar toda la generación aleatoria de parámetros de prueba y, en su lugar, usar valores fijos (es decir, marcadores de posición o const).

Actualmente, xUnit no expone la API para cambiar el nombre para mostrar y reemplazar los datos generados con marcadores de posición. Creé un problema para ellos (ver aquí ), sin embargo, la respuesta de Brad es que es irreal y sugieren simplemente deshabilitar el descubrimiento, lo que ya estamos haciendo.

o limitar de otro modo la siembra de valores de parámetros al caso de prueba en sí.

Desafortunadamente, eso no es posible actualmente para nuestro producto y muchas cosas deberían reescribirse para respaldar una semilla única.

Datos de miembros

En la documentación aquí tienes otra muestra (la he reescrito 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));
    }
}

Es absolutamente legal para xUnit ya que hay DisableDiscoveryEnumeration atributo

La línea de fondo

Parece que xUnit proporciona instrumentos para comprender si la prueba es volátil o no (mediante el soporte de enumeración previa al descubrimiento). Puede usar la implementación de VS como muestra para comprender cómo manejan eso y cómo hacen lo mismo en su producto. Probablemente, simplemente usen xUnit SDK y sus receptores de mensajes.

Dado que tanto R # como VS admiten este tipo de teorías, me hace pensar que en realidad todo está bien con nuestro producto.

En cuanto a NUnit, hablemos de eso después, ya que aún no lo he investigado. Probablemente, no tenemos una API para eso.

¿Podría compartir su opinión con respecto al soporte de xUnit dados mis hallazgos? ¿Agregará soporte para
xUnit (detener, volver a ejecutar todas las pruebas) y detenerse para mostrar esa advertencia de incompatibilidad? 😉

Parece que le debo una disculpa. El caso de uso que ha descrito anteriormente funciona correctamente en NCrunch, por las razones que ha explicado. Xunit está evitando la enumeración previa de la teoría y la está colapsando en una sola prueba donde se identifica y ejecuta de manera segura. Al probar esto ahora, puedo confirmar que NCrunch lo hace correctamente. Parece que no tenemos un problema obvio con InlineAutoData.

No estoy seguro de por qué esto me falló antes. Actualmente soy incapaz de crear un escenario en el que falle. Sé que algunos usuarios me mencionaron que InlineAutoData no estaba funcionando, aunque supongo que deberán presentarse y proporcionar ejemplos de dónde es este el caso.

Me gustaría llamar su atención sobre un caso de uso específico que sé que romperá tanto NCrunch como VS Runner. Supongo que también rompería ReSharper y TD.NET, aunque no los he probado porque no los tengo 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)
        {

        }
    }
}

El código anterior fallará en todos los escenarios de ejecución selectiva. Sin embargo, pasará si las pruebas se descubren y ejecutan en el mismo paso. Este escenario fue el catalizador detrás de la advertencia de NCrunch sobre AutoFixture, ya que los usuarios estaban haciendo esto y pidiendo soporte. Dado que no sabía que AutoFixture deshabilitaba la enumeración previa, había asumido (incorrectamente) que InlineAutoData era el mismo.

Mi suposición actual es que usted no apoya tal escenario. ¿Es esto correcto?

Al probar esto ahora, puedo confirmar que NCrunch lo hace correctamente.

¡Eso es genial! Me alegra saber que, en realidad, xUnit es totalmente compatible con NCrunch 🎉 En cuanto a NUnit, siempre ha sido torpe y tenemos que investigar qué podemos hacer allí.

Sin embargo, sigo observando problemas con NCrunch y AutoFixture. Actualmente tengo el proyecto xUnit con AutoFixture y si cambio incluso una sola línea, todas las pruebas se vuelven a ejecutar. Parece que habilita dicho comportamiento cuando detecta AutoFixture para asegurarse de que no se pierda nada.

¿Es eso así? En caso afirmativo, ¿podría solucionarlo para deshabilitar dicho comportamiento para xUnit, ya que todo está bien allí?

Me gustaría llamar su atención sobre un caso de uso específico que sé que romperá tanto NCrunch como VS Runner.
Mi suposición actual es que usted no apoya tal escenario. ¿Es esto correcto?

Sí, ese escenario romperá a todos los corredores. Sin embargo, como se señaló correctamente en algún lugar de su foro, eso no se debe a AutoFixture, ya que podría escribir algo como esto que tampoco 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 escenario, es su responsabilidad deshabilitar manualmente el descubrimiento previo, para que se vea así (preste atención a la propiedad 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 realidad, se supone que es un escenario muy raro, ya que tenemos los atributos AutoData y InlineAutoData para la generación de datos. Además, AutoFixture es simplemente una herramienta y es responsabilidad del desarrollador usarla correctamente.

No movería NCrunch a un modo especial simplemente porque hay personas que pueden usar la herramienta incorrectamente. Lo mejor que podemos hacer aquí es poner un problema conocido en algún lugar para describir este escenario en particular y pedirle a la gente que use xUnit correctamente (ya que es posible que no lo sepan).

¿Podría confirmar que ejecuta las pruebas de una manera especial si detecta AutoFixture y, de ser así, podría desactivar ese modo para xUnit (para NUnit es mejor dejarlo como está)? También es probable que esta página también se actualice.

Por el momento, NCrunch no implementa ningún manejo especial para AutoFixture fuera de la advertencia de compatibilidad. El comportamiento que ha experimentado probablemente se deba al modo de motor que ha seleccionado. Es completamente configurable: si cambia al modo 'Ejecutar pruebas afectadas automáticamente, otras manualmente', creo que verá que el motor se comporta de la manera que espera.

Con lo que he aprendido de usted, me siento listo para eliminar por completo la advertencia de AutoFixture de NCrunch. Los usuarios ya me habían convencido para que lo reformulara, ya que quedó claro desde el principio que la advertencia era demasiado amplia y que algunas características de AutoFixture seguían funcionando correctamente. Creo que he entendido muy mal cómo se implementa AutoFixture en xunit.

Así que supongo que este es probablemente el mejor de los casos para nosotros. El caso de uso que más me rompió no es técnicamente compatible de todos modos, y todo lo demás está funcionando bien. Mientras tanto, estaré feliz de intentar olvidar mi propia vergüenza por haber probado y verificado esto con una conclusión incorrecta, si puede encontrar un motivo para perdonarme por la advertencia de compatibilidad excesivamente entusiasta.

Mientras tanto, estaré feliz de intentar olvidar mi propia vergüenza por haber probado y verificado esto con una conclusión incorrecta, si puede encontrar un motivo para perdonarme por la advertencia de compatibilidad excesivamente entusiasta.

¡No hay problema! Está absolutamente bien y todos estamos aquí para ayudarnos mutuamente a entender las cosas 😅 Es genial que hayas seguido el boleto y lo discutimos, es demasiado 🥇

Con lo que he aprendido de usted, me siento listo para eliminar por completo la advertencia de AutoFixture de NCrunch.

Bueno, todavía tenemos problemas con NUnit (aunque estamos en camino ), por lo que este mensaje parece ser relevante para los proyectos de NUnit. Probablemente, tenga sentido deshabilitar eso solo para xUnit, a menos que introduzcamos soporte completo para NUnit (o al menos una forma de habilitar ese soporte).

Todavía tengo una cosa que no me queda clara. ¿Qué significa que no admite, por ejemplo, AutoFixture y NUnit? Sí, los nombres de las pruebas son diferentes para cada vez, sin embargo, ¿importa si vuelve a ejecutar todas las pruebas (si el modo de motor está configurado así)? ¿O significa que no admite más el motor "Solo afectados" para ellos? Mi pensamiento era que en lugar de decir No support , probablemente sea mejor limitarse a algunos escenarios particulares que no admitimos, mientras que los de descanso deberían estar bien.

'Ejecutar pruebas impactadas automáticamente, otras manualmente'

No pude encontrar esta configuración en mi instalación 3.10.0.20 . ¿Te refieres a la configuración Only consider tests 'Out of date' if they are 'Impacted' que debería establecerse en true ? Lo siento si me perdí eso en alguna parte, soy un poco nuevo en este producto ...

Actualización de documentación

Probablemente tenga sentido no _remove_ case con xUnit y AutoFixture de esta página, sino que describa cómo usarlo correctamente (use el atributo DisableDiscoveryEnumeration ). También sería genial describir el ejemplo de "Caso de prueba NUnit con nombre inconsistente" para xUnit y pedir usar el atributo DisableDiscoveryEnumeration junto con MemberDataAttribute .

Todavía tengo una cosa que no me queda clara. ¿Qué significa que no admite, por ejemplo, AutoFixture y NUnit? Sí, los nombres de las pruebas son diferentes para cada vez, sin embargo, ¿importa si vuelve a ejecutar todas las pruebas (si el modo de motor está configurado así)? ¿O significa que no admite más el motor "Solo afectados" para ellos? Mi pensamiento era que en lugar de decir Sin soporte, probablemente sea mejor limitarse a algunos escenarios particulares que no admitimos, mientras que los de descanso deberían estar bien.

Esto se debe a la vida útil de la prueba bajo NCrunch. NCrunch tiene un estado importante que se asigna a cada prueba (piense en el resultado de aprobado / reprobado, datos de cobertura de código, datos de rendimiento, salida de seguimiento, etc.). Estos datos persisten mientras la prueba continúe siendo "descubierta" por el marco de pruebas, incluso entre sesiones de VS. Cuando el marco de prueba no informa ninguna prueba con el mismo identificador, se considera que la prueba ha desaparecido y se destruye todo el estado.

Cuando se crea una prueba usando parámetros inestables, cada llamada al marco de prueba para descubrir pruebas da como resultado la creación de una prueba completamente nueva, porque el identificador de la prueba ha cambiado. El resultado es que cada vez que NCrunch llama a NUnit para descubrir pruebas (consistentemente después de cada compilación del proyecto de prueba), se descarta todo el estado retenido para las pruebas con parámetros inestables. Entonces eso es malo. Significa que la detección de impactos no funcionará, y el motor hace un montón de trabajo extra volviendo a ejecutar las pruebas y revisando los resultados transitorios.

Sin embargo, el problema es más profundo. Si el vertido del estado de prueba fuera el único problema real, el manejo de las pruebas inestables aún podría "funcionar" en el sentido de que el motor las ejecutaría y los resultados serían reportados. Los problemas más profundos provienen de la paralelización, la ejecución selectiva y el procesamiento distribuido de NCrunch.

Para realizar la ejecución en paralelo, NCrunch necesita utilizar varios procesos de prueba que ejecutan pruebas en paralelo. La mecánica de NUnit es tal que las pruebas deben descubrirse antes de que puedan ejecutarse. Esto significa que debe haber un paso de descubrimiento completamente separado ejecutado dentro de cada proceso utilizado para la ejecución, por lo que si tenemos dos procesos, entonces necesitamos descubrir las pruebas dos veces. Si las pruebas tienen parámetros inestables, cada proceso tendrá un conjunto de pruebas completamente diferente, lo que hará imposible que el motor divida la lista maestra completa de pruebas entre los procesos para su ejecución. Este problema también se extiende cuando se usa procesamiento distribuido, porque el proceso de ejecución remota se ejecuta en hardware diferente en un entorno completamente diferente.

También está el tema de la ejecución selectiva. El modo de operación predeterminado de NCrunch es crear siempre un nuevo proceso de prueba cuando se le indica específicamente que ejecute una prueba. Esto es para despejar la pizarra y ser lo más consistente posible con otros corredores. Esta característica no puede funcionar con parámetros inestables, porque generar un nuevo proceso de prueba requiere redescubrir las pruebas, que posteriormente no se pueden identificar si sus parámetros han cambiado.

NUnit tiene su propio sistema de identificación interno que podría usarse para identificar pruebas con parámetros inestables entre procesos, pero este sistema de identificación se basa en la secuencia de generación de la prueba (es decir, es incremental). Dicho sistema no puede ser utilizado por ningún ejecutor de pruebas que necesite administrar el estado de la prueba en varias versiones de un conjunto de prueba, porque si el usuario crea una nueva prueba, todas las ID se saldrán de la secuencia y los datos se volverán peligrosamente engañosos. . Los desarrolladores de NUnit han expresado interés en alejarse de este sistema basado en secuencias y adoptar ID generados a partir de los propios atributos de prueba, lo que sería similar a cómo lo hace Xunit (y probablemente no funcionaría con parámetros inestables).

Sigo creyendo que la mejor manera de resolver estos problemas es realizar una siembra consistente de los parámetros inestables. Siempre existe el concepto de que las pruebas deben ser repetibles y consistentes, lo cual es difícil de lograr si las pruebas aleatorizan completamente todas sus entradas. En la práctica real, una prueba que genera datos sembrados aleatoriamente para su ejecución es una prueba completamente nueva cada vez que se genera, ya que el código puede comportarse de manera diferente según los datos que recibe.

No pude encontrar esta configuración en mi instalación 3.10.0.20. ¿Se refiere a la configuración de Solo considerar pruebas como 'Desactualizadas' si están 'Afectadas' que debe establecerse en verdadero? Lo siento si me perdí eso en alguna parte, soy un poco nuevo en este producto ...

Vaya al menú NCrunch, elija 'Establecer modo de motor', y debería ver la opción allí. Si no está allí, es posible que esté usando una solución que fue ejecutada por una versión mucho más antigua de NCrunch y solo muestra modos de motor heredados. Simplemente creando una nueva solución en algún lugar debería resolver esto.

@remcomulder ¡Vaya! ¡Gracias por una explicación tan detallada! Ahora veo que, de hecho, es más fácil decir que AutoFixture & NUnit no es compatible actualmente ya que hay algunos problemas ENORMES bajo el capó 😅

Sigo creyendo que la mejor manera de resolver estos problemas es realizar una siembra consistente de los parámetros inestables.

En realidad, en este PR tenemos una idea un poco diferente. Queremos modificar el nombre de la prueba para que sea estable. Por ejemplo, una prueba como esta:

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

el nombre de la prueba será:

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

El nombre será siempre el mismo durante cada descubrimiento / ejecución, mientras que los valores reales de los argumentos serán diferentes para cada vez.

Dado su profundo conocimiento de NUnit, ¿cómo evaluaría este enfoque? ¿Funcionará para ti? Espero que use un nombre de teoría, en lugar de vincularse a valores de argumentos particulares. Por lo tanto, si el nombre de la prueba es estable, no debería tener ningún problema, ya que ahora es identificable. ¿Podría confirmar antes de que comencemos a implementar esto? ☺️

Siempre existe el concepto de que las pruebas deben ser repetibles y consistentes, lo cual es difícil de lograr si las pruebas aleatorizan completamente todas sus entradas.

Probablemente, algún día apoyaremos una semilla estable para que las pruebas se puedan reproducir con los mismos argumentos, sin embargo, actualmente estamos bastante lejos de eso, por lo que no es realista 😕 Más bien, esperamos que las afirmaciones de los usuarios sean lo suficientemente precisas para comprenderlas más adelante. por qué la prueba falló incluso si la entrada fue aleatoria en algunos rangos.

Dado su profundo conocimiento de NUnit, ¿cómo evaluaría este enfoque? ¿Funcionará para ti? Espero que use un nombre de teoría, en lugar de vincularse a valores de argumentos particulares. Por lo tanto, si el nombre de la prueba es estable, no debería tener ningún problema, ya que ahora es identificable. ¿Podría confirmar antes de que comencemos a implementar esto? ☺️

Desafortunadamente, mi conocimiento de NUnit está lejos de ser profundo :( NCrunch básicamente solo toma el nombre NUnit y lo usa para generar el identificador. Entonces, en teoría, siempre que su solución cambie / estabilice el nombre físico de la prueba como devuelto por la API NUnit, entonces deberíamos estar bien aquí
para NCrunch al menos.

Algo a tener en cuenta es la posibilidad de que un usuario cree múltiples pruebas con la misma firma. Si los parámetros del nombre se reducen a tipos sin formato, esto se vuelve mucho más probable / posible. Siempre que conozca estos escenarios, probablemente podría codificar un error o algo para desalentarlo.

@remcomulder Solo para actualizarlo, para que finalmente podamos cerrar este problema.

Como se ha comentado anteriormente, el marco xUnit se admite de forma nativa. Sin embargo, para NUnit, el problema no estaba claro ya que no admite pruebas con nombres volátiles.

Recientemente fusionamos un PR y lanzamos una nueva versión de AutoFixture ( v3.51.0 ) que agrega soporte para nombres estables para NUnit. Por ahora, las acciones manuales son necesarias desde el lado del usuario (ver aquí ), sin embargo, en la v4 lo haré listo para usar.

Acabo de probar y descubrí que si uso el enfoque anterior, NCrunch solo puede ejecutar pruebas modificadas y parece que ahora funciona correctamente. No estoy seguro de si se requieren algunas acciones de su parte (por ejemplo, documentar eso en alguna parte). También estaría bien si prueba esa nueva función y nos hace saber si funciona bien ahora, para que podamos descansar 😄

@zvirja Gracias por contarme con esto. Le di a este trabajo una prueba rápida y me parece sólido. Al eliminar los elementos aleatorios de los nombres de las pruebas, el corredor puede identificar constantemente las pruebas en todas las sesiones y todo parece ir bien :)

Sin embargo, tengo una idea que creo que podría ahorrarnos algo de tiempo en la asistencia al usuario. Un problema que todos encontramos con el software es que muchas personas no leen los documentos antes de utilizar una herramienta. Es útil saber que ahora podemos asesorarlos sobre cómo resolver los problemas de nombres únicos en NUnit, pero el mejor enfoque es siempre hacer que el problema se resuelva solo.

Observo que, de forma predeterminada, AutoFixture utilizará VolatileNameTestMethodBuilder. Acepto que esto es por razones de compatibilidad con versiones anteriores y estoy de acuerdo en que esto es sensato. Pero, ¿qué pasaría si permitiéramos que este valor predeterminado se anulara mediante una variable de entorno? Si pudiéramos especificar una variable de entorno (digamos, 'AutoFixture.FixedTestNames' == '1') para forzar a AutoFixture a usar VolatileNameTestMethodBuilder, sería posible que un corredor especificara el constructor por adelantado, sin que el usuario tuviera que hacer nada. Esto también sería una ventaja para las personas que usan múltiples corredores, ya que podrían usar implícitamente diferentes constructores para cada corredor (sin ningún esfuerzo requerido) y obtener lo mejor de ambos mundos.

¿Qué piensas?

Le di a este trabajo una prueba rápida y me parece sólido.

¡Eso es genial! 🎉 Lo que significa que podemos cerrar este problema ya que ahora todo funciona bien. Gracias por las pruebas y su participación aquí 🥇

¿Qué piensas?

Creo que terminé con una solución mucho mejor y más simple: haremos de FixedNameTestMethodBuilder una estrategia predeterminada en la v4 (nuestra próxima versión importante) que se lanzará en los próximos meses. El PR apropiado ya ha sido aprobado , por lo que el código estará allí. Por lo tanto, trabajaremos bien desde el primer momento y si alguien necesita nombres de prueba volátiles, optará por participar manualmente, entendiendo claramente las consecuencias.

Más tarde, podríamos hacer algo como sugirió: agregar una estrategia de cambio que inspeccione las variables de entorno / AppConfig, sin embargo, prefiero hacerlo solo si es realmente necesario.

Creo que terminé con una solución mucho mejor y más simple: haremos de FixedNameTestMethodBuilder una estrategia predeterminada en la v4 (nuestra próxima versión importante) que se lanzará en los próximos meses.

Eso funcionará muy bien para mí :) ¡Estoy feliz! Gracias por todo tu esfuerzo.

Genial 😉 Gracias de nuevo por sus respuestas y colaboración 👍

Estoy cerrando este ya que no se requieren más acciones de ambos lados.

@remcomulder @zvirja Solo quería decir que esta discusión (que me ayudó a entender un tema similar), y la dedicación que ha demostrado aquí, ¡no es más que asombrosa! Gracias a ambos por sus excelentes productos.