Autofixture: Проблемы интеграции NCrunch и AutoFixture

Привет, я разработчик NCrunch.

Я буду счастлив работать с вами, чтобы найти решение этой проблемы. К сожалению, с текущим дизайном у меня нет вариантов решения проблемы исключительно на моей стороне точки интеграции. Я считаю, что мой бегун, вероятно, не единственный, у кого возникли проблемы с текущим дизайном.

Как вы, вероятно, поняли из различной документации и сообщений на форуме поддержки, которые я написал, корень проблемы заключается в случайной генерации тестовых параметров AutoFixture. Поскольку параметры теста являются критическим элементом при идентификации теста и его последующем выполнении, выборочное выполнение тестов становится невозможным, если параметры меняются каждый раз, когда тест создается / обнаруживается.

Единственный надежный способ, который я могу придумать для решения этой проблемы, - это удалить все случайные генерации тестовых параметров и вместо этого использовать фиксированные значения (например, заполнители или константы) или иным образом ограничить заполнение значений параметров самим тестовым примером. Таким образом, тесты всегда будут точно такими же, и их можно будет последовательно найти такими же, как и любой другой тест. Каждый пользователь, с которым я имел дело, который использовал AutoFixture для генерации параметров, делал это для параметров, которые им не нужны для целей тестирования, поэтому я надеюсь, что этот подход может не иметь реальных недостатков в глазах пользователя. . Преимущество этого заключается в том, что он также будет сразу работать со всеми версиями NCrunch и не потребует каких-либо изменений кода в NCrunch или любом другом средстве выполнения.

@remcomulder Большое спасибо за участие - очень признательны! Я немного исследовал это и хотел бы поделиться своими выводами. Все мои выводы применимы только к

TL DR: xUnit поддерживает такие теории, и NCrunch также должен поддерживать их для xUnit. Для NUnit - это открытый вопрос, и я еще не исследовал его.

Функция, которую мы используем, кажется _легальной_ для xUnit. У нас есть собственный TestDataDiscoverer, который указывает, что наши теории не могут быть обнаружены заранее (потому что мы генерируем случайные данные). Позже мы украсим наш учитывает этот атрибут и не разрешает значения параметров во время обнаружения.

Я считаю, что мой бегун, вероятно, не единственный, у кого возникли проблемы с текущим дизайном.

На самом деле это не так, и R # и VS прекрасно работают с такими теориями. Они также позволяют повторно запустить конкретную теорию, даже если она содержит автоматически сгенерированные данные. Я бы посоветовал сосредоточиться на VS, поскольку он также содержит фазы обнаружения и запуска и имеет открытый исходный код.

Рассмотрим следующий тестовый код:

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

Проект тестовой библиотеки .NET Framework. VS 2017.3. Целевая база: 4.5.2. Установленные пакеты:

• xunit 2.2.0
• xunit.runner.visualstudio 2.2.0
• AutoFixture 3.50,6
• AutoFixture.Xunit2 3,50,6

Если вы запустите обнаружение в VS, вы увидите следующий результат:

Как вы могли заметить, для теорий, поддерживающих обнаружение данных ( StableInlineTest ), VS runner показывает фактические данные, с которыми будет запускаться тест ( 1 ). Для тестов, которые не поддерживают обнаружение данных и содержат автоматически сгенерированные данные ( VolatileTest , VolatileTestWithInline ), VS не обнаруживает теоретические случаи и показывает вам только всю теорию. Только после запуска вы сможете увидеть значения для этого конкретного вызова:

Теперь вы можете повторно запустить конкретную теорию, и она снова запустит _все случаи теории_.

Как видите, на самом деле есть способ поддержать такие теории, и xUnit отлично с этим справляется. NCrunch должен принимать во внимание тот факт, что некоторые теоретические случаи невозможно предвосхитить. Для таких теорий вам нужно повторно запустить всю теорию, а не конкретный случай. Я не понимаю, почему это невозможно.

Единственный надежный способ решить эту проблему, который я могу придумать, - это удалить все случайные генерации тестовых параметров и вместо этого использовать фиксированные значения (например, заполнители или константы).

В настоящее время xUnit не предоставляет API для изменения отображаемого имени и замены сгенерированных данных заполнителями. Я создал для них проблему (см. Здесь ), однако Брэд отвечает, что это нереально, и они предлагают просто отключить обнаружение, что мы уже делаем.

или иным образом ограничьте набор значений параметров самим тестовым примером.

К сожалению, в настоящее время это невозможно для нашего продукта, и многие вещи необходимо переписать для поддержки одного семени.

Данные участника

В документации здесь у вас есть еще один образец (я переписать его 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));
    }
}

Это абсолютно законно для xUnit, так как есть атрибут DisableDiscoveryEnumeration . Это работает так же, как и в примере выше - теоретические случаи не раскрываются заранее.

Суть

Похоже, что xUnit предоставляет инструменты, позволяющие понять, является ли тест изменчивым или нет (с помощью поддержки перечисления до обнаружения). Вы можете использовать реализацию VS в качестве образца, чтобы понять, как они справляются с этим и делают то же самое в вашем продукте. Скорее всего, они просто используют xUnit SDK и свои приемники сообщений.

Учитывая, что и R #, и VS прекрасно поддерживают такие теории, это заставляет меня думать, что на самом деле с нашим продуктом все в порядке ..

Что касается NUnit - давайте обсудим это позже, поскольку я еще не исследовал это. Наверное, такого API у нас нет.

Не могли бы вы поделиться своим мнением о поддержке xUnit с учетом моих выводов? Вы добавите поддержку
xUnit (прекратить повторный запуск всех тестов) и перестать показывать это предупреждение о несовместимости? 😉

Похоже, я должен извиниться перед вами. Вариант использования, который вы описали выше, правильно работает в NCrunch по причинам, которые вы объяснили. Xunit избегает предварительного перечисления теории и сворачивает ее в единый тест, где она безопасно идентифицируется и выполняется. Проверив это сейчас, я могу подтвердить, что NCrunch делает это правильно. Похоже, у нас нет очевидной проблемы с InlineAutoData.

Я не уверен, почему это не помогло мне раньше. В настоящее время я не могу создать сценарий, в котором он потерпит неудачу. Я знаю, что у меня были пользователи, которые упоминали мне, что InlineAutoData не работает, хотя я предполагаю, что им нужно будет выступить и предоставить примеры того, где это так.

Я хотел бы обратить ваше внимание на конкретный вариант использования, который, как мне известно, нарушает работу NCrunch и VS Runner. Я предполагаю, что это также нарушит работу ReSharper и TD.NET, хотя я не тестировал их, поскольку у меня их нет:

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

        }
    }
}

Приведенный выше код завершится ошибкой во всех сценариях выборочного выполнения. Однако он будет пройден, если тесты будут обнаружены и выполнены на одном шаге. Этот сценарий стал катализатором предупреждения NCrunch об AutoFixture, поскольку пользователи делали это и просили поддержки. Учитывая, что я не знал об отключении предварительного перечисления AutoFixture, я предположил (ошибочно), что InlineAutoData был таким же.

Мое настоящее предположение состоит в том, что вы не поддерживаете такой сценарий. Это верно?

Проверив это сейчас, я могу подтвердить, что NCrunch делает это правильно.

Замечательно! Рад слышать, что на самом деле xUnit полностью поддерживается NCrunch 🎉 Что касается NUnit - он всегда был неуклюжим, и нам нужно изучить, что мы можем там сделать.

Однако я все еще наблюдаю проблемы с NCrunch и AutoFixture. В настоящее время у меня есть проект xUnit с AutoFixture, и если я изменю хотя бы одну строку, все тесты будут повторно запущены. Похоже, вы включаете такое поведение при обнаружении AutoFixture, чтобы ничего не упустить.

Это так? Если да, не могли бы вы исправить это, чтобы отключить такое поведение для xUnit, поскольку там все в порядке?

Я хотел бы обратить ваше внимание на конкретный вариант использования, который, как мне известно, нарушает работу NCrunch и VS Runner.
Мое настоящее предположение состоит в том, что вы не поддерживаете такой сценарий. Это верно?

Да, этот сценарий сломает всех бегунов. Однако, как было правильно указано где-то на вашем форуме, это не из-за AutoFixture, так как вы можете написать что-то вроде этого, что также не будет работать:

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

    }
}

В таком сценарии вы обязаны вручную отключить предварительное обнаружение, чтобы оно выглядело следующим образом (обратите внимание на свойство 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)
    {

    }
}

На самом деле, это должен быть очень редкий сценарий, поскольку у нас есть атрибуты AutoData и InlineAutoData для генерации данных. Кроме того, AutoFixture - это просто инструмент, и разработчик несет ответственность за его правильное использование.

Я бы не стал переводить NCrunch в специальный режим просто потому, что есть люди, которые могут неправильно использовать инструмент. Лучшее, что мы можем здесь сделать, - это поместить где-нибудь известную проблему, чтобы описать этот конкретный сценарий и попросить людей правильно использовать xUnit (поскольку они могут не знать об этом).

Не могли бы вы подтвердить, что вы запускаете тесты особым образом, если вы обнаруживаете AutoFixture, и если да, не могли бы вы отключить этот режим для xUnit (для NUnit лучше оставить его как есть). Также вероятно, что эту страницу также следует обновить.

На данный момент NCrunch не реализует никакой специальной обработки для AutoFixture, кроме предупреждения о совместимости. Поведение, которое вы испытали, вероятно, связано с выбранным вами режимом двигателя. Он полностью настраивается - если вы переключитесь в режим «Запускать затронутые тесты автоматически, другие вручную», я думаю, вы увидите, как движок ведет себя так, как вы ожидаете.

Благодаря тому, что я узнал от вас, я чувствую себя готовым полностью удалить предупреждение AutoFixture из NCrunch. Пользователи уже убедили меня перефразировать его, поскольку очень рано стало ясно, что предупреждение было слишком широким и некоторые функции AutoFixture все еще работали правильно. Думаю, я совершенно неправильно понял, как AutoFixture реализован в xunit.

Так что я думаю, что это, вероятно, лучший сценарий для нас. Вариант использования, который больше всего меня сломал, технически все равно не поддерживается, а все остальное работает нормально. Между тем, я буду счастлив попытаться забыть собственное смущение по поводу того, что я проверил и проверил это до неверного заключения, если вы найдете причину простить меня за чрезмерное предупреждение о совместимости.

Между тем, я буду счастлив попытаться забыть собственное смущение по поводу того, что я проверил и проверил это до неверного заключения, если вы найдете причину простить меня за чрезмерное предупреждение о совместимости.

Не стоит беспокоиться! Это абсолютно нормально, и мы все здесь, чтобы помочь друг другу разобраться в вещах 😅 Замечательно, что вы выполнили заявку, и мы обсудили это - это уже слишком

Благодаря тому, что я узнал от вас, я чувствую себя готовым полностью удалить предупреждение AutoFixture из NCrunch.

Что ж, у нас все еще есть проблемы с NUnit (хотя мы находимся в пути ), поэтому это сообщение выглядит актуальным для проектов NUnit. Вероятно, имеет смысл отключить это только для xUnit, если мы не введем полную поддержку NUnit (или, по крайней мере, способ включить эту поддержку).

У меня все еще есть одна вещь, которая мне непонятна. Что означает, что вы не поддерживаете, например, AutoFixture и NUnit? Да, названия тестов различаются каждый раз, но имеет ли значение, если вы повторно запустите все тесты (если так установлен режим двигателя)? Или это означает, что вы больше не поддерживаете для них движок «Только на удар»? Я подумал, что вместо того, чтобы говорить No support , вероятно, лучше сузиться до некоторых конкретных сценариев, которые мы не поддерживаем, в то время как остальные должны подойти.

«Запускать затронутые тесты автоматически, другие - вручную»

Мне не удалось найти этот параметр в моей установке 3.10.0.20 . Вы имеете в виду настройку Only consider tests 'Out of date' if they are 'Impacted' которая должна быть установлена ​​на true ? Извините, если я где-то это пропустил - я немного новичок в этом продукте ..

Обновление документации

Вероятно, имеет смысл не _ удалять_ регистр с xUnit и AutoFixture с этой страницы, а вместо этого описать, как его правильно использовать (используйте атрибут DisableDiscoveryEnumeration ). Также было бы здорово описать пример «Тестовый пример NUnit с несогласованным именем» для xUnit и попросить использовать атрибут DisableDiscoveryEnumeration вместе с MemberDataAttribute .

У меня все еще есть одна вещь, которая мне непонятна. Что означает, что вы не поддерживаете, например, AutoFixture и NUnit? Да, названия тестов различаются каждый раз, но имеет ли значение, если вы повторно запустите все тесты (если так установлен режим двигателя)? Или это означает, что вы больше не поддерживаете для них движок «Только на удар»? Я подумал, что вместо того, чтобы говорить «Нет поддержки», возможно, лучше сузить круг конкретных сценариев, которые мы не поддерживаем, тогда как остальные подойдут.

Это связано с продолжительностью жизни теста в NCrunch. NCrunch имеет важное состояние, которое назначается каждому тесту (подумайте о результате прохождения / неудачи, данных о покрытии кода, данных о производительности, выводе трассировки и т. Д.). Эти данные сохраняются до тех пор, пока тест продолжает «обнаруживаться» тестовой платформой, даже между сессиями VS. Когда платформа тестирования сообщает об отсутствии теста с тем же идентификатором, тест считается пройденным, и все состояние уничтожается.

Когда тест создается с использованием нестабильных параметров, каждый вызов тестовой среды для обнаружения тестов приводит к созданию совершенно нового теста, потому что идентификатор теста изменился. В результате каждый раз, когда NCrunch вызывает NUnit для обнаружения тестов (последовательно после каждой сборки тестового проекта), все состояния, сохраняемые для тестов с нестабильными параметрами, отбрасываются. Так это плохо. Это означает, что обнаружение столкновений не сработает, и движок проделает кучу дополнительной работы, повторно запуская тесты и просматривая переходные результаты.

Однако проблема гораздо глубже. Если бы сброс тестового состояния был единственной реальной проблемой, обработка нестабильных тестов все еще могла бы «работать» в том смысле, что они все еще запускались бы движком, и результаты были бы сообщены. Более глубокие проблемы возникают из-за распараллеливания, выборочного выполнения и распределенной обработки NCrunch.

Для параллельного выполнения NCrunch необходимо использовать несколько тестовых процессов, которые выполняют тесты параллельно. Механика NUnit такова, что тесты должны быть обнаружены, прежде чем они могут быть выполнены. Это означает, что внутри каждого процесса, используемого для выполнения, должен выполняться целый отдельный шаг обнаружения, поэтому, если у нас есть два процесса, нам нужно обнаруживать тесты дважды. Если тесты имеют нестабильные параметры, каждый процесс будет иметь совершенно другой набор тестов, что делает невозможным для механизма разделение полного основного списка тестов между процессами для выполнения. Эта проблема также расширяется при использовании распределенной обработки, поскольку процесс удаленного выполнения выполняется на другом оборудовании в совершенно другой среде.

Также существует проблема выборочного исполнения. Режим работы NCrunch по умолчанию заключается в том, чтобы всегда создавать новый тестовый процесс, когда ему специально сказано запустить тест. Это сделано для того, чтобы очистить планку и быть максимально последовательным с другими бегунами. Такая функция не может работать с нестабильными параметрами, потому что создание нового тестового процесса требует повторного обнаружения тестов, которые впоследствии не могут быть идентифицированы, если их параметры изменились.

У NUnit действительно есть собственная внутренняя система идентификаторов, которую можно использовать для идентификации тестов с нестабильными параметрами между процессами, но эта система идентификаторов основана на последовательности генерации тестов (т.е. она инкрементная). Такую систему не может использовать ни один исполнитель тестов, которому необходимо управлять состоянием теста в нескольких версиях тестовой сборки, потому что, если пользователь создаст новый тест, все идентификаторы выпадут из последовательности, и данные станут опасно вводящими в заблуждение. . Разработчики NUnit выразили заинтересованность в том, чтобы отойти от этой системы, основанной на последовательностях, и перейти к идентификаторам, сгенерированным из самих тестовых атрибутов, что было бы похоже на то, как это делает Xunit (и, вероятно, не будет работать с нестабильными параметрами).

Я по-прежнему считаю, что лучший способ решить эти проблемы - выполнить последовательное заполнение нестабильных параметров. Всегда существует концепция, согласно которой тесты должны быть повторяемыми и последовательными, чего трудно достичь, если тесты полностью рандомизируют все свои входные данные. На практике тест, который генерирует случайные данные для своего выполнения, представляет собой совершенно новый тест каждый раз, когда он генерируется, поскольку код может вести себя по-разному в зависимости от данных, которые он вводит.

Мне не удалось найти этот параметр в моей установке 3.10.0.20. Вы имеете в виду параметр Учитывать только тесты «Устаревшие», если они имеют значение «Затронуто», для которого должно быть установлено значение «Истина»? Извините, если я где-то это пропустил - я немного новичок в этом продукте ..

Перейдите в меню NCrunch, выберите «Установить режим двигателя», и вы должны увидеть там опцию. Если его там нет, возможно, вы используете решение, которое было выполнено гораздо более старой версией NCrunch, и оно показывает только устаревшие режимы движка. Простое создание где-то нового решения должно решить эту проблему.

@remcomulder Вау! Спасибо за столь подробное объяснение! Теперь я вижу, что действительно легче сказать, что AutoFixture и NUnit в настоящее время не поддерживаются, поскольку под капотом есть ОГРОМНЫЕ проблемы 😅

Я по-прежнему считаю, что лучший способ решить эти проблемы - выполнить последовательное заполнение нестабильных параметров.

На самом деле, в этом пиаре мы имеем несколько иное представление. Мы хотим изменить имя теста, чтобы оно было стабильным. Например, такой тест:

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

имя теста будет:

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

Имя будет всегда одним и тем же во время каждого обнаружения / выполнения, в то время как фактические значения аргументов будут различаться каждый раз.

Учитывая ваше глубокое знание NUnit, как бы вы оценили этот подход? Это сработает для вас? Я ожидаю, что вы используете название теории, а не привязываетесь к определенным значениям аргументов. Следовательно, если имя теста стабильное, у вас не должно возникнуть никаких проблем, поскольку теперь его можно идентифицировать. Не могли бы вы подтвердить, прежде чем мы начнем внедрять это? ☺️

Всегда существует концепция, согласно которой тесты должны быть повторяемыми и последовательными, чего трудно достичь, если тесты полностью рандомизируют все свои входные данные.

Возможно, когда-нибудь мы будем поддерживать стабильное семя, чтобы тесты можно было воспроизводить с теми же аргументами, однако в настоящее время мы довольно далеки от этого, поэтому это нереально 😕 Скорее, мы ожидаем, что утверждения пользователей будут достаточно точными, чтобы позже понять почему тест не прошел, даже если входные данные были рандомизированы в некоторых диапазонах.

Учитывая ваше глубокое знание NUnit, как бы вы оценили этот подход? Это сработает для вас? Я ожидаю, что вы используете название теории, а не привязываетесь к определенным значениям аргументов. Следовательно, если имя теста стабильное, у вас не должно возникнуть никаких проблем, поскольку теперь его можно идентифицировать. Не могли бы вы подтвердить, прежде чем мы начнем внедрять это? ☺️

К сожалению, мои знания о NUnit далеко не глубокие :( NCrunch в основном просто берет имя, которое NUnit возвращает ему, и использует его для генерации идентификатора. Итак, теоретически, если ваше решение изменило / стабилизировало физическое имя теста как возвращается NUnit API, тогда все должно быть в порядке
по крайней мере для NCrunch.

Следует обратить внимание на возможность создания пользователем нескольких тестов с одной и той же подписью. Если параметры в имени сокращаются до необработанных типов, это становится гораздо более вероятным / возможным. Если вы знаете об этих сценариях, вы, вероятно, можете написать код ошибки или что-то еще, чтобы не допустить ее.

@remcomulder Просто

Как уже говорилось выше, фреймворк xUnit изначально поддерживается. Однако для NUnit проблема не была ясна, поскольку он не поддерживает тесты с изменчивыми именами.

Недавно мы объединили PR и выпустили новую версию AutoFixture ( v3.51.0 ), которая добавляет поддержку стабильных имен для NUnit. На данный момент ручные действия требуются со стороны пользователя (см. Здесь ), однако в версии 4 я собираюсь сделать это нестандартно.

Я только что протестировал и обнаружил, что если я использую описанный выше подход, NCrunch сможет запускать только модифицированные тесты, и теперь кажется, что он работает правильно. Я не уверен, требуются ли какие-то действия с вашей стороны (например, где-то задокументировать). Также будет хорошо, если вы протестируете эту новую функцию и сообщите нам, хорошо ли она работает сейчас, чтобы мы могли отдохнуть 😄

@zvirja Спасибо, что

У меня есть идея, которая, я думаю, может сэкономить нам время на поддержку пользователей. Одна проблема, с которой мы все сталкиваемся с программным обеспечением, заключается в том, что многие люди не читают документацию, прежде чем берут в руки инструмент. Полезно знать, что теперь мы можем посоветовать им, как решить проблемы с уникальными именами в NUnit, но лучший подход - всегда решать проблему сама.

Замечу, что по умолчанию AutoFixture будет использовать VolatileNameTestMethodBuilder. Я согласен с тем, что это сделано из соображений обратной совместимости, и согласен с тем, что это разумно. Но что, если мы позволим переопределить это значение по умолчанию с помощью переменной среды? Если бы мы могли указать переменную среды (скажем, 'AutoFixture.FixedTestNames' == '1'), чтобы заставить AutoFixture использовать VolatileNameTestMethodBuilder, бегун мог бы указать конструктор заранее, без необходимости что-либо делать пользователю. Это также будет бонусом для людей, которые используют несколько бегунов, поскольку они могут неявно использовать разные конструкторы для каждого бегуна (без каких-либо усилий) и получить лучшее из обоих миров.

Что вы думаете?

Я провел быструю проверку этой работы, и она мне кажется убедительной.

Это потрясающе! 🎉 Это означает, что мы можем закрыть эту проблему, так как теперь все работает нормально. Спасибо за тестирование и участие здесь 🥇

Что вы думаете?

Я думаю, что в итоге я получил гораздо лучшее и более простое решение - мы сделаем FixedNameTestMethodBuilder стратегией по умолчанию в версии 4 (наш следующий крупный выпуск), которая будет выпущена в ближайшие месяц или два. Соответствующий PR уже утвержден , поэтому код будет. Таким образом, мы будем работать нормально из коробки, и если кому-то понадобятся изменчивые имена тестов - он подпишется вручную, четко понимая последствия.

Позже мы могли бы сделать что-то вроде того, что вы предложили, - добавить стратегию переключения, которая проверяет переменные среды / AppConfig, однако я предпочитаю делать это только в том случае, если это действительно необходимо.

Думаю, в итоге я получил гораздо лучшее и более простое решение - мы сделаем FixedNameTestMethodBuilder стратегией по умолчанию в версии 4 (наш следующий крупный выпуск), которая будет выпущена в ближайшие месяц или два.

Это отлично подойдет для меня :) Я счастлив! Спасибо за все ваши усилия.

Круто 😉 Еще раз спасибо за ваши ответы и сотрудничество 👍

Я закрываю это, так как больше никаких действий с обеих сторон не требуется.

@remcomulder @zvirja Просто хотел сказать, что это обсуждение (которое помогло мне разобраться в похожей проблеме) и самоотверженность, которую вы продемонстрировали здесь, просто потрясающие! Спасибо вам обоим за ваши замечательные продукты.