Комментарии 8

E2E расшифровывается как End-to-End. Обновил статью, чтобы уточнить.

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

Давайте начнем с простого вопроса. Ваши коллеги — они программисты или тестировщики?


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

Можно, пожалуйста, ссылку на исследование, которое бы подтвердило это утверждение?


E2E тесты действительно требуют в среднем больше времени для прогона, нежели модульные.

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


А как Вы считаете, можно ли использовать только E2E тесты?

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

Под коллегами имею ввиду разработчиков. Исследованиями здесь не оперирую, все это не более чем философия и изложение субъективного опыта работы. Согласен, стоило написать "по моему опыту", чтобы не вводить в заблуждение объективностью. Поправлю.


Понятно, что ситуация варьируется от места к месту, но то, что конкретно в Вашем случае только запуск системы для прогона E2E тестов занимает больше времени, чем все модульные тесты, может быть показательно как раз с точки зрения метрик.


Возможно, стоит подумать о том, как эту систему можно сделать проще и быстрее, возможно декомпозировать? Или время старта E2E теста подразумевает время запуска инструментария тестирования?


Почему Вы считаете, что разработчику тяжело поддерживать E2E тесты? Для меня, как разработчика, не представляет сложности написать HTTP-запрос, кинуть сообщение в Rabbit или Kafka, потыкать web-интерфейc или взаимодействовать с БД. Это даже проще, потому как ты просто используешь API уже существующего ПО. Возможно, я что-то упускаю?

Под коллегами имею ввиду разработчиков.

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


Исследованиями здесь не оперирую, все это не более чем философия и изложение субъективного опыта работы. Согласен, стоило написать "по моему опыту",

Ну вот а по моему опыту написание E2E тестов занимает намного больше времени, чем написание модульных. И что мы будем делать с этим противоречащим друг другу опытом?


Возможно, стоит подумать о том, как эту систему можно сделать проще и быстрее, возможно декомпозировать?

Подумали. Нельзя. Дальше?..


Почему Вы считаете, что разработчику тяжело поддерживать E2E тесты?

По собственному опыту. Мне — тяжело.


Ну вот возьмем один пример из жизни, прямо вот свеженький. Я правлю небольшой кусочек системы, отвечающий за чтение конфигурации. И там, в числе прочего есть параметр, который ограничивает количество неких "узлов" во входящем запросе некоего АПИ. Я пишу "неких" не потому, что это NDA, а потому, что я с этим АПИ никогда не работал, не поддерживал его в этой системе, и для меня это сепульки. Что мне надо, чтобы это покрыть E2E-тестами. Во-первых, мне надо научиться подменять конфигурацию системы перед запуском теста. В принципе, на этом моя компетенция как разработчика уже закончилась, это уже сложно. Во-вторых, нужно понять, где этот API в системе есть, и как создать и проверить ситуацию, в которой сработает ограничение на число "узлов".


А теперь, значит, возьмем следующий кусок той же конфигурации: работу с БД. Теперь мне надо проверить, что оттуда корректно читается тип провайдера БД — для этого мне придется раздобыть все поддерживаемые БД — и таймаут запроса. Как стабильно проверить таймаут, я, как разработчик, не знаю, и, если честно, знать и не хочу.


Для меня, как разработчика, не представляет сложности [...] потыкать web-интерфейc

Ну вот для меня, как для разработчика бэкендов и всяких странных распределенных систем, потыкать web-интерфейс из теста — сложно.


Возможно, я что-то упускаю?

О, вы упускаете деплоймент. Вот, значит, еще одна система которая я разрабатываю. Там "типичная" такая облачная распределенка на AWS: API Gateway, Step Function, Lambda, Textract. Во-первых, чтобы прогнать там E2E тест, это все надо сдеплоить. Деплоймент занимает от 20 до 40 минут. В принципе, на этом месте уже можно было бы остановиться, потому что это делает тестирование разработчиком в процессе разработки невозможным. Но если вам этого мало, есть во-вторых: мы не можем проверять конкретные результаты автоматически, поскольку они зависят от работы Textract, а она недетерминирована. А еще есть в-третьих: все эти сервисы стоят денег.

Пирамида тестирования — теоретическое предположение. В практике бывает очень по-разному. И всем очевидно, что е2е автотесты — штука хрупкая. Но успешно прошедшие в регрессе такие тесты берегут массу времени для проверки сквозного процесса. В общем, как всегда, надо искать в конкретных случаях баланс.

В целом, согласен с Вами и вся разработка ПО это, в принципе, про баланс. Но вот с тем, что E2E это "хрупкие" тесты, не соглашусь. Современный инструментарий для backend и frontend позволяет писать E2E тесты, которые не имеют свойства ломаться.

Современный инструментарий для backend и frontend позволяет писать E2E тесты, которые не имеют свойства ломаться.

Сами себя переписывают при изменении функционала?

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