Тесты MemberData отображаются как один тест вместо множества

Я потратил много времени, пытаясь понять это в своем проекте. Это связанное обсуждение Github от самого @NPadrutt очень помогло, но все еще сбивало с толку.

Суть в следующем: [MemberInfo] сообщит об одном групповом тесте, если предоставленные объекты для каждого теста не могут быть полностью сериализованы и десериализованы путем реализации IXunitSerializable.

Фон

Моя собственная тестовая установка была примерно такой:

public static IEnumerable<object[]> GetClients()
{
    yield return new object[] { new Impl.Client("clientType1") };
    yield return new object[] { new Impl.Client("clientType2") };
}

[Theory]
[MemberData(nameof(GetClients))]
public void ClientTheory(Impl.Client testClient)
{
    // ... test here
}

Тест выполнялся дважды, по одному разу для каждого объекта из [MemberData], как и ожидалось. По опыту @NPadrutt, в обозревателе тестов появился только один элемент вместо двух. Это связано с тем, что предоставленный объект Impl.Client не может быть сериализован ни одним интерфейсом, поддерживаемым xUnit (подробнее об этом позже).

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

Объекты не просто сериализуются во время обнаружения для подсчета перестановок; каждый объект также десериализуется во время выполнения теста при запуске теста.

Таким образом, любой объект, который вы предоставляете с помощью [MemberData], должен поддерживать полную циклическую (де-)сериализацию. Сейчас это кажется мне очевидным, но я не смог найти никакой документации по этому вопросу, пока пытался понять это.

Решение

• Убедитесь, что каждый объект (и любой не-примитивный объект, который он может содержать) может быть полностью сериализован и десериализован. Реализация xUnit IXunitSerializable сообщает xUnit, что это сериализуемый объект.

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

TestClientBuilder

public class TestClientBuilder : IXunitSerializable
{
    private string type;

    // required for deserializer
    public TestClientBuilder()
    {
    }

    public TestClientBuilder(string type)
    {
        this.type = type;
    }

    public Impl.Client Build()
    {
        return new Impl.Client(type);
    }

    public void Deserialize(IXunitSerializationInfo info)
    {
        type = info.GetValue<string>("type");
    }

    public void Serialize(IXunitSerializationInfo info)
    {
        info.AddValue("type", type, typeof(string));
    }

    public override string ToString()
    {
        return $"Type = {type}";
    }
}

Тест

public static IEnumerable<object[]> GetClients()
{
    yield return new object[] { new TestClientBuilder("clientType1") };
    yield return new object[] { new TestClientBuilder("clientType2") };
}

[Theory]
[MemberData(nameof(GetClients))]
private void ClientTheory(TestClientBuilder clientBuilder)
{
    var client = clientBuilder.Build();
    // ... test here
}

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

MemberData может работать со свойствами или методами, которые возвращают IEnumerable объекта[]. Вы увидите отдельный результат теста для каждого выхода в этом сценарии:

public class Tests
{ 
    [Theory]
    [MemberData("TestCases", MemberType = typeof(TestDataProvider))]
    public void IsLargerTest(string testName, int a, int b)
    {
        Assert.True(b>a);
    }
}

public class TestDataProvider
{
    public static IEnumerable<object[]> TestCases()
    {
        yield return new object[] {"case1", 1, 2};
        yield return new object[] {"case2", 2, 3};
        yield return new object[] {"case3", 3, 4};
    }
}

Однако, как только вам нужно будет пройти сложные пользовательские объекты, независимо от того, сколько у вас будет тестовых случаев, в окне вывода теста будет отображаться только один тест. Это не идеальное поведение и действительно очень неудобно при отладке того тестового случая, в котором произошел сбой. Обходной путь — создать собственную оболочку, которая будет производной от IXunitSerializable.

public class MemberDataSerializer<T> : IXunitSerializable
    {
        public T Object { get; private set; }

        public MemberDataSerializer()
        {
        }

        public MemberDataSerializer(T objectToSerialize)
        {
            Object = objectToSerialize;
        }

        public void Deserialize(IXunitSerializationInfo info)
        {
            Object = JsonConvert.DeserializeObject<T>(info.GetValue<string>("objValue"));
        }

        public void Serialize(IXunitSerializationInfo info)
        {
            var json = JsonConvert.SerializeObject(Object);
            info.AddValue("objValue", json);
        }
    }

Теперь вы можете использовать свои пользовательские объекты в качестве параметров для Xunit Theories и по-прежнему просматривать/отлаживать их как независимые результаты в окне запуска тестов:

public class UnitTest1
{
    [Theory]
    [MemberData("TestData", MemberType = typeof(TestDataProvider))]
    public void Test1(string testName, MemberDataSerializer<TestData> testCase)
    {
        Assert.Equal(1, testCase.Object.IntProp);
    }
}

public class TestDataProvider
{
    public static IEnumerable<object[]> TestData()
    {
        yield return new object[] { "test1", new MemberDataSerializer<TestData>(new TestData { IntProp = 1, StringProp = "hello" }) };
        yield return new object[] { "test2", new MemberDataSerializer<TestData>(new TestData { IntProp = 2, StringProp = "Myro" }) };      
    }
}

public class TestData
{
    public int IntProp { get; set; }
    public string StringProp { get; set; }
}

Надеюсь это поможет.

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

Реализуйте свой собственный MyTheoryAttribute, расширяющий FactAttribute, вместе с MyTheoryDiscoverer, реализующим IXunitTestCaseDiscoverer, и несколько пользовательских MyTestCase, расширяющих TestMethodTestCase и реализующих IXunitTestCase по своему вкусу. Ваши пользовательские тестовые примеры должны распознаваться MyTheoryDiscoverer и использоваться для инкапсуляции ваших пронумерованных тестовых случаев теории в форме, видимой для платформы Xunit, даже если переданные значения не сериализуются изначально Xunit и не реализуют IXunitSerializable.

Что наиболее важно, нет необходимости изменять ваш драгоценный тестируемый код!

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

Прямая ссылка на соответствующую папку с кодом поддержки Xunit приведена ниже:

Код поддержки тестирования DjvuNet

Чтобы использовать его, либо создайте отдельную сборку с этими файлами, либо включите их непосредственно в свой тестовый проект.

Использование точно такое же, как и с Xunit TheoryAttribute, и поддерживаются как ClassDataAttribute, так и MemberDataAttribute, т. е.:

[DjvuTheory]
[ClassData(typeof(DjvuJsonDataSource))]
public void InfoChunk_Theory(DjvuJsonDocument doc, int index)
{
    // Test code goes here
}


[DjvuTheory]
[MemberData(nameof(BG44TestData))]
public void ProgressiveDecodeBackground_Theory(BG44DataJson data, long length)
{
    // Test code goes here
}

Кредит также принадлежит другому разработчику, но, к сожалению, я не могу найти его репозиторий на github.

На данный момент ReSharper может отображать все тесты MemberData с пользовательскими параметрами, когда ваши пользовательские классы переопределяют ToString().

Например :

public static TheoryData<Permission, Permission, Permission> GetAddRuleData()
{
    var data = new TheoryData<Permission, Permission, Permission>
    {
        {
            new Permission("book", new[] {"read"}, null),
            new Permission("book", new[] {"delete"}, new[] {"2333"}),
            new Permission("book", new[] {"delete", "read"}, new[] {"*", "2333"})
        },
        {
            new Permission("book", new[] {"read"}, null),
            new Permission("music", new[] {"read"}, new[] {"2333"}), new Permission
            {
                Resources = new Dictionary<string, ResourceRule>
                {
                    ["book"] = new ResourceRule("book", new[] {"read"}, null),
                    ["music"] = new ResourceRule("music", new[] {"read"}, new[] {"2333"}),
                }
            }
        }
    };
    return data;
}

Permission переопределяет ToString(), затем в ReSharper Test Session Explorer:

Простая альтернатива заключается в том, что если вы используете основной проект .net, вместо использования vstest explorer вы можете запускать свои тесты в командной строке, используя тест dotnet.

Результаты:

• получить общее количество тестов
• сумма, прошедшая
• сумма, которая не удалась

Для неудачных тестов данных элементов вы получите соответствующие значения параметров для каждого из неудавшихся тестов данных элементов.