О чем пойдет речь
Статья представляет собой небольшой туториал для разработчиков на .NET и описывает способы, которыми можно упростить создание юнит-тестов для больших (и не очень) проектов с табличными данными или списками сложных объектов, нуждающихся в проверке.
Тут не будет крутых алгоритмов, машинного обучения, и искуственного интеллекта, а будет немного рутинная задача, которую мы будем шаг за шагом облегчать.
Опыт применения описываемых методов был наработан на реальном финтех-проекте и сэкономил много усилий на отладку и проверку алгоритмов, позволив создавать и проверять тестовые данные и операции над ними напрямую из данных бизнес-анализа.
Туториал состоит из трех частей:
Аппрувал-тесты. Что это такое и зачем они нужны.
Представление результатов тестирования в виде таблиц. Как можно упростить восприятие результатов аппрувал-теста.
Подготовка тестовых данных в табличной форме. Как подружить .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):
TaxRateService - сервис, который предоставляет данные для начисления прогрессивного налога в виде коллекции TaxRate в зависимости от переданого типа налога (в нашем простейшем примере это Flat/Progressive. В реальном мире набор параметров может быть намного сложнее).
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# для почти автоматической подготовки исходных тестовых данных из таблиц, то юнит-тест превращается в универсальный метод проверки сложной логики.
Спасибо за внимание!