Смотрел доклад: Боль и страдания api-тестов / Альгис Фатеев и там в 1001 раз говорили, что связанные тесты зло. К своему ужасу узнал, что у нас в команде есть люди, которых это возмущает!
Даже phpunit для таких людей придумал аннотацию Depends одобрив таким образом страдания тысяч и миллионов программистов.
Давайте пример. У нас софт для ветеринарных клиник и нам нужно протестировать создание счета. Мы будем писать end-to-end тест или API тест.
Для проверки создания счета, нам нужен Клиент, Питомец и Доктор. Есть паттерн AAA, который гласит, что тест состоит из подготовки, действия и проверки. На первый взгляд он выглядит неудачно. Ведь у нас есть тест на создание клиента, почему нам не использовать его? Мы же программисты и любим DRY. А еще это производительность, ведь не оптимально создавать клиента для каждого теста, сильно нагружаются сервера.
Мы напишем такой код(псевдо):
# Это псеводкод
public function test_create_client(): void
{
...
}
#[Depends('test_create_client')]
public function test_create_pet(): void
{
...
}
#[Depends('test_create_pet')]
public function test_create_doctor(): void
{
...
}
#[Depends('test_create_doctor')]
public function test_create_invoice(): void
{
...
}
Какая мощь, мы потратили минимум времени и протестировали всё-всё-всё. Код наш переиспользуемый и мы думаем, что мы классные, но какие с этим могут быть проблемы?
Тоже самое мы могли бы сделать написа один боготест где тестовый метод длинной в 200-300 строк проверял бы все это последовательно. У такого боготеста будут схожие проблемы.
Читаемость
Как готовится тест для нас не очевидно, нам нужно изучить всю цепочку зависимостей. Удобнее это увидеть в самом test_create_invoice
.
Если тестеры или люди бизнеса захотят почитать тесты они совсем с ума сойдут.
Тест нельзя запустить один
Это всегда отнимает время при отладке, ты видишь сломанный тест в консоли, по привычке запускаешь один тест и пытаешься понять почему он не запускается. Нужно сначала понять что у теста есть связи, а потом понять как это всё запустить. Придется запускать весь класс. Если мы будем добавлять какие-то var_dump в общие методы, то все тесты нам будут их выбрасывать.
Запускать все тесты может быть долго, если это UI тест.
Мы не знаем какие тесты упали
Если проблема произошла в начале цепочки, то следующие тесты просто не выполнились. Мы не знаем сломаны они или нет. Даже если сломался тест создания счета, то может это произошло из-за теста создания клиента, создался клиент из черного списка, к примеру, мы даже не уверенны какой тест точно сломался, ведь ошибка в тесте на создание счета может быть вызвана ошибками в других тестах.
Изменения в одном тесте влияют на другие
Мы получили классический лапшекод. Тянем за одну спагетину, а тянется все тарелка. Нам тяжело, страшно редактировать тесты внутри цепочки. Нужно всегда держать в голове всю цепочку целиком.
Проблемы при написании новых тестов
Мы растем и развиваемся, нам будут нужны новые тесты. Как мы напишем тест на создание счета: без указания доктора, для клиента из черного списка, для умершего пациента? Как мы будем настраивать цепочки, сколько мы будем думать над рефакторингом и лениться писать новые тесты? Что если мы будем добавлять тесты на создание разных видов клиентов и докторов, как выстраивать зависимости в таком случае? Нам понадобится тестировать списание со склада при создании счетов, куда мы добавим проверки списания, в тест создания счета?
Не параллелится
С таким подоходом вы не сможете написать большое количество тестов, но если вдруг справитесь и захотите это запустить в паралелль, чтобы ускорить работу тестов, то эти цепочки тестов и длинные боготесты будут вам очень мешать.
Вывод
Пожалуйста, будьте внимательны и осторожны, соблюдайте принципы написания тестов. Принципы написаны может и не кровью как техника безопасности, но слезами и потом. Вы скажете, что у вас всё не так и Depends у вас хороший, он не такой глупый как в этом примере. Не обманывайте себя, ваш код такой же. Для каждого теста пусть будет свой отдельный ARRANGE и пусть каждый тест за собой приберёт.
Только на начальном этапе работы с легаси проектом, когда вам нужно здесь и сейчас получить пользу от тестов, вы пишите свои первые несколько тестов тестируя самые длинные и важные сценарии в системе. В одном тесте создаёте клиента и проверяете, создаёте питомца и проверяете, и т. д. Это очень дешево и полезно. При появлении в системе отдельных тестов на эти операции, это боготесты нужно рефакторить и удалять.