О чем пойдет речь

Статья представляет собой небольшой туториал для разработчиков на .NET и описывает способы, которыми можно упростить создание юнит-тестов для больших (и не очень) проектов с табличными данными или списками сложных объектов, нуждающихся в проверке.

Тут не будет крутых алгоритмов, машинного обучения, и искуственного интеллекта, а будет немного рутинная задача, которую мы будем шаг за шагом облегчать.

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

Туториал состоит из трех частей:

1. Аппрувал-тесты. Что это такое и зачем они нужны.

2. Представление результатов тестирования в виде таблиц. Как можно упростить восприятие результатов аппрувал-теста.

3. Подготовка тестовых данных в табличной форме. Как подружить .NET и табличные файлы через F#.

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

Предполагается, что читатель уже знаком с C#, каким-нибудь из юнит-тест фреймфорков (в коде туториала используется XUnit и Moq) и может написать какие-нибудь базовые ассерты.

Итак, начнем.

Часть 1. Аппрувал тесты.

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

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

Аппрувал тест после выполнения сгенерирует файл ".recieved", правильность которого оценит автор теста. При подтверждении создается файл ".approved", который при последующем выполнении теста будет сравниваться с заново сгенерированным файлом ".recieved". Если возникнут расхождения, считается, что тест не проходит, и фреймворк аппрувал тестов откроет файл в diff-инструменте.

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

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

Часть 1. Пример.

Структура солюшена

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

Проекты солюшена:

• Domain

  В предметной области все просто. Есть класс TaxRate, который содержит информацию о минимальном и максимальном доходе, на который необходимо делать начисление по процентной ставке Rate. Например, Tax Rate с MinAmount = 0, MaxAmount = 100 и Rate = 0.1 будет означать, что на доход с 0 до 100 долларов будет начислен налог по ставке 10%. А также есть класс IncomeRecord, который определяет запись полученного работником EmployeeId на дату Date дохода в размере Amount.

• DAL

  В примере нет полноценного DataAccessLayer, но мы определим интерфейсы для репозиториев и UnitOfWork, чтобы замокать их в тесте сервиса.

• BL

  В бизнес-логике, на которую мы будем писать тесты, два anemic сервиса (но аппрувал тесты подходят и для DDD):

  1. TaxRateService - сервис, который предоставляет данные для начисления прогрессивного налога в виде коллекции TaxRate в зависимости от переданого типа налога (в нашем простейшем примере это Flat/Progressive. В реальном мире набор параметров может быть намного сложнее).

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

И, наконец, проект с юнит тестами.

Тестируются оба сервиса, с подготовкой данных для TaxCalculationService в классе TestEmployeeRecordsDataFactory. Удобная и быстрая подготовка данных для теста это отдельный момент и мы будем подробно рассматривать его в части 3.

Начинаем тестирование

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

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

Подключим аппрувал тесты из nuget и перепишем наш тест с их использованием. А также убедимся, что в системе есть diff-merge инструмент, используемый по умолчанию (tortoise merge или kdiff подойдет).

[Fact]
public void ShouldProvideCorrectRates_ForProgressiveTaxType()
{
    var response = _service.GetTaxRates(ETaxType.Progressive).ToList();

    Assert.Equal(5, response.Count);

    Assert.Equal(0.00m, response[0].Rate);
    Assert.Equal(0,     response[0].MinAmount);
    Assert.Equal(1000,  response[0].MaxAmount);

    Assert.Equal(0.05m, response[1].Rate);
    Assert.Equal(1001,  response[1].MinAmount);
    Assert.Equal(5000,  response[1].MaxAmount);

    Assert.Equal(0.10m, response[2].Rate);
    Assert.Equal(5001,  response[2].MinAmount);
    Assert.Equal(10000, response[2].MaxAmount);

    Assert.Equal(0.20m,   response[3].Rate);
    Assert.Equal(10_001,  response[3].MinAmount);
    Assert.Equal(100_000, response[3].MaxAmount);

    Assert.Equal(0.35m,   response[4].Rate);
    Assert.Equal(100_001, response[4].MinAmount);
    Assert.Null(response[4].MaxAmount);
}

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

Подключим аппрувал тесты из nuget и перепишем наш тест с их использованием. А также убедимся, что в системе есть diff-merge инструмент, используемый по умолчанию (tortoise merge или kdiff подойдет).

Навесим на класс атрибуты [UseReporter(typeof(DiffReporter))] и [UseApprovalSubdirectory("Results")], чтобы тесты корректно запускались и складывали результаты не в директорию с кодом, а в отдельную папку. А также можно указать, какой репортер будет использоваться в ходе запуска тестов в пайплайне (не в режиме отладки).

#if DEBUG
    // DIFF REPORTER is used to approve test results on a developer's machine
    [UseReporter(typeof(DiffReporter))]
#else
    // QUIET REPORTER is used when we run tests in CI/CD pipeline 
    [UseReporter(typeof(QuietReporter))]
#endif
    [UseApprovalSubdirectory("Results")]
    public class TaxRateServiceTest

Новый вариант будет выглядеть так:

[Fact]
public void ShouldProvideCorrectRates_ForFlatTaxType()
{
    var response = _service.GetTaxRates(ETaxType.Flat);
    var jsonResponse = JsonConvert.SerializeObject(response, Formatting.Indented);

    ApprovalTests.Approvals.Verify(jsonResponse);
}

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

Допустим, все значения нас устраивают, и мы разрешаем конфликт, выбирая все строчки из .received файла.

Запускаем тесты еще один раз - и любуемся на их зеленый цвет. Логика TaxRate покрыта.

Теперь попробуем внести изменения в логику и запустить тесты еще раз:

new TaxRate { Id = 2, Rate = 0.00m, MinAmount = 0, MaxAmount = 1200 },

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

Часть 2. Представление результатов тестирования в виде таблиц.

Результаты выполнения аппрувал-теста чаще всего представляют в виде json. Это удобно для многих случаев - небольших объектов, больших древовидных структур, готовых ответов API, а также анонимных классов, которые содержат только необходимый для проверки результат.

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

В этом случае гораздо удобнее представлять данные в виде таблицы. Было бы здорово, если бы существовали diff-инструменты, которые могли бы представлять csv или excel данные в табличном виде с возможностью подсветки отличий того или иного поля. К сожалению, форматирование большинства diff-инструментов стандартное, текстовое, и для того, чтобы представить данные в удобном виде, требуется преобразовать их в таблицу с текстовым представлением ячеек (да-да, как в старинных текстовых таблицах времен нортон коммандера).

В таком виде данные становятся гораздо нагляднее и при изменении какого-либо из значений в ячейках таблицы diff-инструмент подсветит только это место.

Часть 2. Пример.

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

[Fact]
public void ShouldProvideCorrectRates_ForProgressiveTaxType_TableFormatting()
{
    var response = _service.GetTaxRates(ETaxType.Progressive);

    var tableFormattedResponse = response.ToStringTable(
        ("Id", r => r.Id),
        ("Min Amount", r => r.MinAmount.ToString(CultureInfo.InvariantCulture)),
        ("Max Amount", r => (r.MaxAmount == decimal.MaxValue 
                             ? "MAX" 
                             : r.MaxAmount.ToString(CultureInfo.InvariantCulture))),
        ("Rate", r => r.Rate.ToString(CultureInfo.InvariantCulture))
    );

    ApprovalTests.Approvals.Verify(tableFormattedResponse);
}

Теперь, при его запуске и расхождениях в результатах программист увидит место ошибки в более наглядном формате:

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

Часть 3. Генерация массива тестовых данных из csv при помощи F#.

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

Ничего нового в том, чтобы парсить csv и переводить данные из табличного формата в коллекцию объектов нет, но, как показала практика, в .NET проще всего это делать при помощи F# благодаря наличию CsvTypeProvider

Часть 3. Пример.

Допустим, мы хотим протестировать работу сервиса по начислению налога (метод GetEmployeeIncomeRecords) на массиве реальных данных, и у нас есть таблица с реальными значениями полученного дохода. Мы бы хотели, чтобы эти данные стали исходными данными для проверки сервиса.

Добавим к солюшену проект F# class library, а к проекту - пакет FSharp.Data. Чтобы воспользоваться возможностью парсинга из csv, нужен следующий код (и да, это будет весь код для парсинга csv):

module CsvDataHelper =

  open System
  open FSharp.Data
  open AdvancedApprovalTests.Domain
  ...

  // EMPLOYEE INCOME RECORD DATA

  [<Literal>]
  let private employeePath = __SOURCE_DIRECTORY__ 
    + "\TestData\EmployeeIncomeRecordHeaders.csv"

  type EmployeeIncomeRecordData = CsvProvider<employeePath, 
    Schema = "int64, int64, date, decimal">
              //id   emp.   date  amount

  let private employeeIncomeRecords (data: EmployeeIncomeRecordData) = 
      data.Rows |> Seq.map(fun row -> 
          (
              IncomeRecord(
                  Id = row.Id,
                  EmployeeId = row.EmployeeId,
                  Date = row.Date,
                  Amount = row.Amount
              )
          )
      )

  let GetEmployeeIncomeRecords (path: string) = 
      let dataSet = EmployeeIncomeRecordData.Load(path)
      employeeIncomeRecords dataSet |> Seq.toArray 

Здесь мы референсим проект Domain, подключаем CsvTypeProvider, который смотрит на лежащий рядом csv файл с заголовками и парой значений, и пишем код метода, который переводит строчки файла в необходимые нам записи. Schema c типами необязательна, но лучше ее прописать для надежности. Далее, просто воспользуемся этим методом в тесте, скормив ему реальный файл с тестовыми данными.

    [Theory]
    [InlineData(
      "./SampleData/TaxRates1.csv", 
      "./SampleData/EmployeeIncomes1.csv")]
    public async Task ShouldCalculateProgressiveTaxCorrectly_DataHelper(
      string taxRatePath, 
      string employeePath)
    {
      var testRecords = CsvDataHelper.GetEmployeeIncomeRecords(employeePath);
      var taxRates = CsvDataHelper.GetTaxRateItems(taxRatePath);

      _incomeRepositoryMock
        .Setup(i => i.GetFiltered(2020))
        .ReturnsAsync(testRecords);

      _rateServiceMock
        .Setup(r => r.GetTaxRates(ETaxType.Progressive))
        .Returns(taxRates);

      var response = await _service.CalculateYearlyTaxAsync(
        new List<long>() { 1 }, 2020, ETaxType.Progressive);

      ApprovalTests.Approvals.Verify(response.ToStringTable());
    }

При запуске аппрувал-теста получим следующий результат:

Employee 1
Total tax 17860.30
Calculated tax:
 | Basis    | Tax      | 
 |---------------------| 
 | 1000.00  | 0.00     | 
 | 3999.00  | 399.90   | 
 | 14999.00 | 2999.80  | 
 | 48202.00 | 14460.60 | 

Ура! Логика начисления нужного нам кейса покрыта, мы можем быть уверены, что на реальных данных сервис поведет себя точно так же, и не бояться, что алгоритм сработает как-то не так.

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

Заключение

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

Спасибо за внимание!