Это был обычный будний день, я начал писать очередной обычный тест, но при написании названия теста что-то пошло не так:
testCustomerRedirectUrlAfterSelectLastTransactionProcessShouldContainsUrlToConfirmRecurringProfilePageWhenTransactionTypeIsCreateRecurringProfile
Примерно на середине я начал осознавать что происходит что-то не то, но я не остановилс
и дописал название теста до конца. Коллеги не оценили такое длиннющее название теста, но мне оно нравится. Сейчас используется что-то вроде testCorrectChangeCustomerRedirectUrl, а детали того что тест тестирует скрыты внутри теста.
Я не могу понять это лвлап, либо я устал под вечер.
Вопрос: Каковы критерии выбора хорошего названия теста?
UPD: Пожалуйста, приведите названия тестов из ваших проектов.
Ответы
Ответ 1
Название для тестов не надо выбирать красивое. Название нужно выбирать функционально
и по возможности короткое -- чтобы по минимальному количеству символов было понятно, что и под какими условиями он тестирует, а также чтобы можно было отличить конкретный тест от тысяч других.
Распространенные шаблоны наименования такие:
TestClass_TestMethod_ConditionAndExpectedResult (для юнит-тестов)
TestMethod_Condition_ExpectedResult (для юнит-тестов)
ConditionAndExpectedResult (для интеграционных тестов, которые тестируют целые блоки функциональности через некоторую входную точку)
При этом если у вас в частях Condition/ExpectedResult слишком много разных условий/результатов
объединенных по "И", то вам нужно пересмотреть либо главную цель теста (что он тестирует), либо главное условие, которое отличает тест от других, и разбить его на несколько отдельных тестов.
Я ратую прежде всего за то, что название должно быть информативным, но при этом настольк
коротким, насколько возможно. Тут точно так же как и со всем остальным кодом -- че
меньше кода, тем меньше времени нужно чтобы его понять, тем проще разбираться с ним
Судя по вашему названию, это не простой маленький юнит-тест, а что-то побольше, поэтому совсем коротким названием тут не обойтись. В вашем случае, если тест класс у вам уже для Customer, я бы ограничился названием SelectLastTransactionProcess_CreateRecurringProfile_RedirectUrlShouldContainConfirmation. В вашем названии много повторений слов: transaction, url, recurring profile и т.д. Они избыточны.
Между длиной и информативностью названия безусловно должен быть баланс. Достаточно
чтоб названия были понятны разработчикам внутри проекта, которые уже обладают контексто
и способны понять, о чем этот тест. И если для этого нужно длину названия сделать н
30 символов, а 40, сделайте. Но не нужно стремиться к тому, чтоб названия были понятн
каждому встречному, попутно рассказывая обо всей системе, поскольку это приводит к таким вот километровым названиям, в которых сложно разобраться. Посмотрите на свой обычный код, посмотрите на названия методов. Вы ведь не описываете в названии метода каждую его деталь, каждую строчку? Вы описываете нечто главное, а остальное спрятано внутри. Точно так же и с тестовыми методами.
Кто-нибудь может ещё рассказать что делать с названиями интеграционных тестов
> где 100500 различных условий?
К примеру биллинг, принимает на вход 5-10 видов прайс-листов и в
зависимости от их комбинаций и комбинаций их параметров (тоже примерно
5-10) должен выдавать различные суммы на выход. Контейнер отправляемый
в биллинг занимает ~30 строчек. Если в стиле поста называть тесты то
это будет
testPayoutDebtorToGateOntopGateTransactionAmountGateToCreditorFlatPayinDebtorToGateOntopTotalTransactionAmountGateToCreditorOntopTransactionAmount,
причем не с полным контекстом.
Нужно рассчитать итоговую сумму исходя из
того что прайс-листы могли быть настроены следующим образом: Тип
комиссии прайс-листа типа основной сделки - inside/total, комиссия
0.1% + 0.5руб cверху, расчет вести от оборота. Второй комиссионный прайс-лист ontop/gate.. ещё в таком же стиле раз 10 и пара неявных
зависимостей прайс-листов друг от друга.
Я бы сказал, что вам нужен параметрический тест. Это такой тест, который одним кодо
тестирует разные наборы данных. Например, в терминах тестового фреймворка xUnit параметрический тест метода Calculator.Add() может выглядеть так:
[Theory] // это параметрический тест
[InlineDate(1, 2, 3)] // наборы данных, т.е. параметры теста
[InlineDate(0, 1, 1)]
[InlineDate(-1, 1, 0)]
public void Calculator_Add_ShouldReturnCorrectResult(int a, int b, int expectedResult)
{
var result = Calculator.Add(a, b);
Assert.AreEqual(result, expectedResult);
}
С параметрическими тестами вам не нужно перечислять все условия в названиях -- названи
содержит только суть теста, что именно тестируется, конкретный кейс. В вашем случа
это что-то вроде РасчетИтоговойСтоимости_ПоОсновнойИДополнительнойСделке (на английский сами переведете, вам область понятнее). А выглядеть ваш тестовый метод может так (при этом в xUnit тестовые данные можно подставлять из свойства и даже из отдельного объекта):
[Theory]
[PropertyData("PriceData")] // тестовые данные находятся в отдельном свойстве
public void РасчетИтоговойСтоимости_ПоОсновнойИДополнительнойСделке(
ComissionType mainComissionType,
Comission mainComission,
CalculationType mainCalculationType,
ComissionType auxComissionType,
Comission auxComission,
CalculationType auxCalculationType,
double expectedPrice)
{
// код теста
}
public static IEnumerable
Комментариев нет:
Отправить комментарий