Автоматизация тестов в .NET: мой опыт со Storm Petrel

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

В этой статье мы рассмотрим Scand Storm Petrel — инструмент для .NET-разработчиков, который автоматизирует однотипную работу по формированию и обновлению ожидаемых значений в тестах. Это особенно актуально при большом количестве тестовых сценариев или сложной структуре тестируемых объектов, что является неотъемлемой частью разработки современных приложений.

Основные проблемы тестирования в .NET

При создании новых юнит или интеграционных тестов разработчики обычно:

• Выбирают тестовый фреймфорк (обычно xUnit, но можно и NUnit, MSTest или их менее известные альтернативы).

• Подбирают библиотеки для мокирования (NSubsitute, Moq, FakeItEasy и т.д.).

• Определяют архитектурные границы и типы тестов (Sociable/Solitary Unit Tests, Integration Tests и т.д.), следуя принципам TDD и шаблону Arrange-Act-Assert.

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

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

• Хранения ожидаемых значений. Здесь есть два основных варианта со своими достоинствами и недостатками:

а. В отдельных файлах (JSON, PDF, PNG, TXT и т.д.).

б. В C# коде: строковые или числовые переменные, константы в assert выражениях, параметры тестов, атрибутов; переменные или методы, в которых инициализированы ожидаемые объекты.

• Формирования и обновления этих значений. Делать это вручную зачастую не является оптимальным способом: много кому знакомы ситуации, когда добавление нового поля в классе или изменение его поведения ведет к ручному исправлению несколько десятков мест в тестовых проектах. Также часто ожидаемый объект является довольно сложным для ручного формирования или перезаписи, поскольку в нем большое количество свойств и вложенных связей.

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

Почему я выбрал Storm Petrel

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

Вариант 1. Храним ожидаемые значения в отдельных файлах

В общем случае в этом варианте имеем слабую связанность (Loose Coupling) между кодом проекта и ожидаемыми значениями.

Достоинства:

• Удобство просмотра ожидаемых файлов (JSON, PDF, PNG, TXT и т.д.) в сторонних специализированных программах.

• Простота автоматического обновления, что экономит время разработки.

Недостатки:

• Не подходит к большей части традиционных тестов.

• Сложность поиска используемых свойства ожидаемых объектов в случае сериализации в JSON, XML или другие форматы.

• Снижение производительности тестов из-за дополнительных операций с файлами или дополнительной сериализации.

Далее, в зависимости от реализации этого варианта, получаем свои особенности.

Вариант 1.1. Вставляем вызовы File.Read/Write в тело тестов

Достоинства:

• Простота и гибкость реализации.

Недостатки:

• Нужен дополнительный код для десериализации, в случае если мы храним ожидаемые объекты как сериализованные значения. Либо сравниваем сами сериализованные значения (обычно строки), что имеет свои очевидные недостатки.

• Нужны дополнительные вызовы File.Write, используемые только для перезаписи файлов, но не в самой логике тестов. Этот File.Write приходится дублировать во всех тестах и держать закомментированным, а раскомментировать только когда разработчик решает перезаписать ожидаемые файлы.

Вариант 1.2. Считываем/записываем ожидаемые значения через инструменты снапшот тестирования

Т.е. используем Verify .NET или его альтернативы: Snapshooter, Meziantou.Framework.InlineSnapshotTesting, ApprovalTests.Net и т.д.

Достоинства:

• Наличие интерактивных инструментов для сравнения и перезаписи снапшотов.

• Встроенные возможности по сериализации объектов.

Недостатки:

• Отсутствие поддержки традиционных тестов. Существующие тесты приходится переделывать под вызовы методов типа Verify(…).

• Более узкие возможности вариативности. Обусловлено тем, что вызовы методов типа Verify(…) выполняют несколько действий, причем по собственным правилам: сериализуют/десериализуют объекты, сравнивают и перезаписывают их. А что будет если у нас специфическая сериализация или сравнение, которые не поддерживаются Verify?

• Существенное время на изучение инструментов. По крайней мере в Verify .NET есть огромное количество NuGet пакетов, адаптеров утилит сравнения и т.д., которые пытаются покрыть все возможные случаи в тестах, что могут встретиться на практике.

Вариант 1.3. NuGet пакет Scand.StormPetrel.FileSnapshotInfrastructure

В этом варианте считываем ожидаемые значения с помощь АПИ этого пакета, а записываем ожидаемые значения через вызов автоматически сгенерированных тестов с суффиксом StormPetrel.

Достоинства:

• Простота тестового кода. Для перезаписи ожидаемых файлов можно запускать автоматически сгенерированные StormPetrel тесты, а дополнительные вызовы File.Write просто не нужны в коде тестов.

• Минимальное влияние на другие аспекты процесса разработки. StormPetrel тесты можно отключить для процесса CI/CD, а включать только в окружении разработчика.

• Унификация структуры ожидаемых файлов.

Недостатки:

• Дополнительное время на изучение инструмента. Однако он состоит из всего лишь двух NuGet пакетов с документацией и примерами.

Вариант 2. Храним ожидаемые значения в C# коде тестового проекта

В отличие от варианта 1, в большинстве случаев здесь имеем сильную связанность (Tight Coupling) между кодом проекта и ожидаемыми значениями, хотя остается возможность организовать слабую связанность при необходимости.

Достоинства:

• Поддержка большей части традиционных тестов.

• Удобство поиска используемых свойств ожидаемых объектов средствами IDE.

• Лучшая производительность тестов из-за отсутствия обращений к файловой системе и дополнительной сериализации.

Недостатки:

• Неудобство использования сторонних программы для просмотра специальных видов ожидаемых значений (JSON, PDF, PNG, TXT и т.д.). Для таких тестов все же лучше использовать варианты для снапшот тестирования.

Далее разделяем вариант 2 на две части.

Вариант 2.1. Формируем или перезаписываем ожидаемые значения вручную

Достоинства:

• Гибкость. Можем разработать тестовый метод в любой форме.

Недостатки:

• Дополнительное время разработки для ручного формирования или перезаписи ожидаемых значений. Крайне актуально при большом количестве тестов, тестовых сценариев или сложной структуры ожидаемых объектов.

Вариант 2.2. Формируем или перезаписываем ожидаемые значения с помощью NuGet пакета Scand.StormPetrel.Generator

Достоинства:

• Сокращение время разработки. Обновляем ожидаемые значения через вызов автоматически сгенерированных тестовых методов с суффиксом StormPetrel. Такие тесты можно запускать как индивидуально, так и массово. Пересматривать обновленные ожидаемые значения, чтобы убедиться в их правильности, никто не отменял.

• Минимальное влияние на другие аспекты процесса разработки. StormPetrel тесты можно отключить для процесса CI/CD, а включать только в окружении разработчика.

Недостатки:

• Неполная поддержка. Находятся примеры тестов, которые требуют либо изменения их кода для совместимости с поддерживаемыми сценариями Storm Petrel, либо внесения изменений в сам Storm Petrel.

Как я внедрил Storm Petrel в проект

В этом разделе опишем наш опыт использования Storm Petrel в одном из реальных проектов - ASP.NET Core сервисе для раскроя панелей. Здесь опустим функциональные и нефункциональные требования к проекту (нужно ли оптимизировать раскрой? Какие проблемы бизнеса мы решаем этим проектом в краткосрочной и долгосрочной перспективе? Требования к клиенту/серверу и т.д.), а будем фокусироваться на основных примерах разработанной функциональности и практике внедрения Storm Petrel.

Контекст: ASP.NET Core сервис для раскроя панелей

Пример: ASP.NET Core сервис, который рассчитывает раскрой настенных панелей. На вход ему приходит массив панелей с высотой и шириной, который вводит менеджер по продажам на специальной веб странице, а на выходе мы должны получить:

• PDF файл с чертежом размещения панелей на производственной ленте размером 1220 x 50 000 мм с учетом технологического отступа в 2 мм.

• Параметры раскроя (погонная длина и площадь занятой ленты, общий периметр и площадь панелей) с учетом технологического отступа и без.

Упрощенный код основного контроллера:

using Microsoft.AspNetCore.Authorization;

using Microsoft.AspNetCore.Mvc;

namespace LayoutApi.Controllers;

[Route("api/[controller]")]

[ApiController]

public class LayoutController : ControllerBase

{

    [AllowAnonymous]

    [HttpPost("calculate")]

    public CalculateResult Calculate(Panel[] request)

    {

        //Реализация вычислений

    }

    [AllowAnonymous]

    [HttpPost("pdf")]

    public FileStreamResult GeneratePdf(Panel[] request)

    {

        //Реализация создания generatedPdfStream

        return File(generatedPdfStream, "application/pdf", "generated_pdf.pdf");

    }

}

Классы, используемые в этом контроллере:

public class Panel

{

    public int Width { get; set; }

    public int Height { get; set; }

}

public class CalculateResult

{

    public Layout Layout { get; set; } = new Layout();

    /// <summary>

    /// Рассчет раскроя с учетом технологического отступа

    /// </summary>

    public Layout LayoutWithTechIndent { get; set; } = new Layout();

}

public class Layout

{

    /// <summary>

    /// Погонная длина, т.е. сколько миллиметров займет весь раскрой на производственной ленте

    /// </summary>

    public int LinearLength { get; set; } = 0;

    public int LinearSquare { get; set; } = 0;

    public int Perimeter { get; set; } = 0;

    public int Square { get; set; } = 0;

}

Класс LayoutController является стабильной границей тестирования, поэтому для него далее будем создавать юнит тесты. Тесты поместим в два отдельных xUnit проекта (традиционные и файл снапшот тесты). Можно их поместить в один проект, но тогда конфигурация Scand Storm Petrel станет более сложной.

Традиционные тесты для проверки параметров раскроя

В проекте традиционных тестов добавим Scand Storm Petrel с параметрами по умолчанию через Scand.StormPetrel.Extension расширение для Visual Studio. В проект тестов это добавит:

- NuGet пакеты ObjectDumper.NET и Scand.StormPetrel.Generator.

- Конфигурационный файл appsettings.StormPetrel.json с необходимыми значениями.

Через расширение можем указать другие варианты конфигурации: пакет VarDump вместо ObjectDumper.NET или свою реализацию интерфейсов из Scand.StormPetrel.Generator.Abstraction. Storm Petrel также можно сконфигурировать вручную без использования расширения на основании документации.

Далее будем следовать основному сценарию Storm Petrel:

https://static.scand.com/com/uploads/primary-use-case.gif

Добавим новый класс с Fact тестом и пустым ожидаемым значением new CalculateResult():

    [Fact]

    public void CalculateTest()

    {

        //Arrange

        var inputPanels = new[]

        {

            new Panel

            {

                Height = 2500,

                Width = 800,

            }

        };

        //Act

        var actual = new LayoutController().Calculate(inputPanels);

        //Assert

        actual.Should().BeEquivalentTo(

            new CalculateResult());

    }

Скомпилируем тестовый проект и запустим сгенерированный тест CalculateTestStormPetrel, что заменит ожидаемое значение new CalculateResult() на актуальное в коде исходного теста CalculateTest:

new CalculateResult

{

    Layout = new Layout

    {

        LinearLength = 2500,

        LinearSquare = 3050000,

        Perimeter = 6600,

        Square = 2000000

    },

    LayoutWithTechIndent = new Layout

    {

        LinearLength = 2504,

        LinearSquare = 3054880,

        Perimeter = 6616,

        Square = 2013216

    }

}

Таким образом, ручная работа по формированию ожидаемого значения в тесте выполнена, а разработчику остается убедиться в том, что сформированное ожидаемое значение корректно. Если значение некорректно, то нужно будет исправить код метода LayoutController.Calculate и повторить процесс перезаписи ожидаемого значения.

Далее очевидно, что у CalculateTest могут изменяться входные значения и, соответственно, ожидаемые. Будем использовать атрибуты Theory и MemberData, а входные и ожидаемые значения передавать в качестве аргументов теста:

  [Theory]

    [MemberData(nameof(CalculateTheoryData))]

    public void CalculateTheoryDataTest(CalculateTestCase testCase, CalculateResult expected)

    {

        //Arrange

        //Act

        var actual = new LayoutController().Calculate(testCase.InputPanels);

        //Assert

        actual.Should().BeEquivalentTo(expected);

    }

где реализация CalculateTheoryData содержит два сценария для примера:

public static TheoryData<CalculateTestCase, CalculateResult> CalculateTheoryData =>

    new()

    {

        {

            new CalculateTestCase(

                "Одна типовая панель",

                new[]

                {

                    new Panel

                    {

                        Height = 2500,

                        Width = 800,

                    }

                }),

            new CalculateResult()

        },

        {

            new CalculateTestCase(

                "Одна минимальная панель",

                new[]

                {

                    new Panel

                    {

                        Height = 1,

                        Width = 1,

                    }

                }),

            new CalculateResult()

        },

    };

где, в свою очередь, дополнительный класс CalculateTestCase является одним из вариантов решения того, что Storm Petrel требует реализации оператора равенства (==) для входных параметров теста. В нашем случае он имеет следующую реализацию:

public record CalculateTestCase(string Name, Panel[] InputPanels)

{

    /// <summary>

    /// Сравниваем только Name, игнорируем остальные свойства.

    /// </summary>

    /// <param name="other"></param>

    /// <returns></returns>

    public virtual bool Equals(CalculateTestCase? other) => other is not null && Name == other.Name;

    public override int GetHashCode() => Name.GetHashCode();

}

Далее аналогично компилируем тестовый проект и запускаем автоматически сгенерированный тест CalculateTheoryDataTestStormPetrel. Пустые ожидаемые значения new CalculateResult() в методе CalculateTheoryData перезапишутся на актуальные и будет достаточно убедиться в их корректности. Метод CalculateTheoryData далее расширяем дополнительными необходимыми тестовыми сценариями.

Файл снапшот тесты для проверки PDF файлов с чертежом раскроя

Для проекта файл снапшот тестов выберем Scand.StormPetrel.FileSnapshotInfrastructure в поле Dumper Expression окна конфигурации Scand.StormPetrel.Extension расширение для Visual Studio. В проект тестов это добавит:

• NuGet пакеты Scand.StormPetrel.FileSnapshotInfrastructure и Scand.StormPetrel.Generator.

• Конфигурационный файл appsettings.StormPetrel.json с необходимыми значениями.

На основании документации Storm Petrel такую же конфигурацию можно создать вручную без использования расширения.

Далее будем следовать основному сценарию File Snapshot Infrastructure:

https://static.scand.com/com/uploads/primary-use-case-2.gif

и его варианту Default Configuration With Custom Options, поскольку нам известно фиксированное расширение pdf для снапшот файлов. Т.е. нам понадобится ModuleInitializer:

using Scand.StormPetrel.FileSnapshotInfrastructure;

using System.Runtime.CompilerServices;

internal static class ModuleInitializer

{

    [ModuleInitializer]

    public static void Initialize()

    {

        SnapshotOptions.Current = new()

        {

            SnapshotInfoProvider = new SnapshotInfoProvider(fileExtension: "pdf"),

        };

    }

}

Приступим теперь к созданию Fact теста:

using FluentAssertions;

using LayoutApi.Controllers;

using Scand.StormPetrel.FileSnapshotInfrastructure;

public class LayoutControllerTest

{

    [Fact]

    public void GeneratePdfTest()

    {

        //Arrange

        var expectedPdfBytes = SnapshotProvider.ReadAllBytes();

        var inputPanels = new[]

        {

            new Panel

            {

                Height = 2500,

                Width = 800,

            }

        };

        //Act

        var actualPdfBytes = new LayoutController()

                                    .GeneratePdf(inputPanels)

                                    .FileStream

                                    .ReadAllBytes();

        //Assert

        actualPdfBytes.Should().Equal(expectedPdfBytes);

    }

}

где ReadAllBytes можно реализовывать по-разному, в нашем случае это будет:

public static class Extensions

{

    public static byte[] ReadAllBytes(this Stream stream)

    {

        using var ms = new MemoryStream();

        stream.CopyTo(ms);

        return ms.ToArray();

    }

}

Скомпилируем тестовый проект и запустим автоматически сгенерированный тест GeneratePdfTestStormPetrel, что в корне проекта создаст файл LayoutControllerTest.Expected/GeneratePdfTest.pdf в соответствие с конфигурацией из ModuleInitializer. Откроем этот pdf файл в браузере или другой программе для просмотра pdf и убедимся, что в файле находятся корректные данные. Если данные некорректны, то нужно будет исправить код метода LayoutController.GeneratePdf и повторить процесс перезаписи ожидаемого pdf файла.

Далее очевидно, что у GeneratePdf могут изменяться входные значения и, соответственно, ожидаемые pdf файлы. Будем использовать атрибуты Theory и MemberData, а входные значения передавать в качестве аргументов теста, причем один из аргументов обязан иметь название useCaseId или должен быть помечен специальным атрибутом согласно документации:

  [Theory]

    [MemberData(nameof(GeneratePdfTheoryData))]

    public void GeneratePdfTheoryDataTest(string useCaseId, Panel[] inputPanels)

    {

        //Arrange

        var expectedPdfBytes = SnapshotProvider.ReadAllBytes(useCaseId);

        //Act

        var actualPdfBytes = new LayoutController()

                                                    .GeneratePdf(inputPanels)

                                                    .FileStream

                                                    .ReadAllBytes();

        //Assert

        actualPdfBytes.Should().Equal(expectedPdfBytes);

    }

где реализация GeneratePdfTheoryData содержит два сценария для примера:

public static TheoryData<string, Panel[]> GeneratePdfTheoryData =>

    new()

    {

        {

            "Одна-типовая-панель",

            new[]

            {

                new Panel

                {

                    Height = 2500,

                    Width = 800,

                }

            }

        },

        {

            "two-panels",

            new[]

            {

                new Panel

                {

                    Height = 2500,

                    Width = 800,

                },

                new Panel

                {

                    Height = 2500,

                    Width = 800,

                }

            }

        },

    };

Далее аналогично компилируем тестовый проект и запускаем автоматически сгенерированный тест GeneratePdfTheoryDataTestStormPetrel. Появятся новые файлы (или перезапишутся при повторном запуске если их байты не будут совпадать с актуальными) LayoutControllerTest.Expected/GeneratePdfTheoryDataTest.Одна-типовая-панель.pdf и LayoutControllerTest.Expected/GeneratePdfTheoryDataTest.two-panels.pdf соответственно. Метод GeneratePdfTheoryData далее расширяем дополнительными необходимыми тестовыми сценариями.

5. Результаты и выводы

Внедрение Storm Petrel значительно ускорило разработку юнит и интеграционных тестов через автоматизацию работы .NET разработчиков по формированию/обновлению ожидаемых значений. Следовательно, это ускорило разработку и самого разрабатываемого приложения. При этом:

• Структура тестовых методов остается традиционной либо несущественно изменяется.

• Остается гибким выбор библиотек для сравнения актуальных и ожидаемых значений, их сериализации/десериализации (при необходимости).

• Используется инфраструктура тестов из .NET: для обновления ожидаемых значений можно запускать сгенерированные StormPetrel тесты как из IDE, так и командной строки dotnet test ... --filter "FullyQualifiedName~StormPetrel".

• Используется инфраструктура .NET Incremental Generators: при необходимости код сгенерированных StormPetrel тестов можно посмотреть в IDE, отладить и понять корневую причину их неполадки.

• Storm Petrel фактически не влияет на процесс CI. Его можно держать отключенным в конфигурационном файле в удаленном репозитории и включать только в окружении разработчика. В крайних случаях можно просто не добавлять Storm Petrel в удаленный репозиторий, а делать это только в локальном окружении.

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

• Документация указывает на массу типовых примеров конфигураций и тестов, где Storm Petrel может переписывать ожидаемые значения.

• Есть возможность игнорировать файлы с кодом в тестовых проектах, где логика Storm Petrel неприменима.

• Scand Storm Petrel является проектом с открытым исходным кодом с вытекающими преимуществами.

Заключение

Scand Storm Petrel является эффективным инструментом, который облегчает и ускоряет разработку .NET проектов. Его можно применять для формирования/обновления ожидаемых значений как при совместной работе над проектами, так и индивидуально в локальном окружении разработчика.

Какие инструменты вы используете для работы с ожидаемыми значениями? Делитесь опытом в комментариях!