Comments 9
Аналитик то системный тест напишет. Только документ будет называться "требования к системе". И возможно "сценарии использования". А вот сколько раз придется автоматизацию этого теста переписывать до конца системы? как бы не чаще, чем выкидывать юнит тесты. Так как если АПИ внешних систем худо бедно зафиксирован и их состав почти не меняется, то пользовательский интерфейс будет переделан миллион раз. А во вторых, половина системных тестов не пройдет до 80% реализации системы. И проку от того, что они были написаны первыми, если они все время красные?
Есть только один маленький нюанс: начать писать юнит-тесты я, как разработчик, могу сразу с началом разработки системы. А начать писать системные тесты я не могу никогда, потому что это требует навыков, которых у меня нет (и получать которые я и не планирую). Поэтому выбора "системные тесты или юнит-тесты" у меня не стоит. У меня стоит выбор "юнит-тесты или никаких тестов", или, при везении, "юнит-тесты или интеграционные тесты".
Поэтому я все еще выбираю писать юнит-тесты.
Можете привести пример системы, которую Вы разрабатывали, но не знали, как покрыть её системными тестами?
Любое веб-приложение, требующее стабильной БД. Особенно если это крупное веб-приложение, на которое я пришел спустя лет пять после его запуска, и где мне надо поправить небольшой кусок в ядре.
(или вот лямбды в AWS, и вообще serverless functions, очень неудобно и дорого покрывать системными тестами)
Я бы мог составить статью, в которой описывается процесс разработки такого веб-приложения в стиле TDD. То есть сначала пишутся системные тесты, а потом — реализация. Вам было бы интересно почитать такую статью?
Пирамида — это свойство которое образуется самостоятельно при разделении тестов на цели и зоны ответственности и выражено оно соотношением стоимости к качеству, меньше стоимость и выше качество. Не нужно пытаться собственноручно выстроить данную пирамиду, руководствуясь лишь тем что UI-тестов должно быть меньше, чем Unit-тестов — ничего хорошего из этого не выйдет.
Ваш вопрос «С чего начать?» некорректен тем, что вы оперируете совершенно разными видами тестов, цели которых очень сильно отличаются. И каждый вид тестов не должен пересекаться с другими и уж тем более нести ответственность за других. Если писать только E2E-тесты, то мы можем отвечать только за то что определённый сценарий действий работает, но не за корректность всех данных по пути этого сценария. Например, если вдруг каким-то образом у вас E2E-тесты начали нести ответственность и за данные на каждом шаге, то спешу порадовать — вы начали писать тесты других видов за счёт E2E-тестов, что само по себе дорогое удовольствие и противоречит пирамиде с которой вы начали. Любые тесты писать необходимо тогда, когда дело доходит до зоны ответственности, которую необходимо покрыть тестами, а не когда вздумается.
Просто для любого нового проекта это абсолютно нормальная ситуация — в какой-то момент понять, что изначальная архитектура или затея вышла не слишком удачной — и что нужно всё (или практически всё) переделывать.
Это абсолютно не нормальная ситуация, это уже вопрос к компетентности и уровню команды, и говорит только о том что с ней явно что-то не так. Использовать это как аргумент против Unit-тестов совершенно глупо. Каждый ответственный разработчик каким-либо образом проверяет работоспособность своего кода, вопрос только лишь в том каким образом? Поднимает целиком всю систему на каждый чих и ручками проверяет? Что-то сильно дорого выходит, не так ли? Это еще ладно если такая возможность вообще есть, а если ее нет? Интересно было бы узнать как обойтись в таком случае без Unit-тестов.
Крайне «больно» писать системные тесты на ранних этапах разработки какого-нибудь функционала. Он часто меняется и не стабилен, поэтому часто приходится оставлять работу на половину, а потом возвращаться к дописыванию этих тестов после того, как фича будет более менее дописана, протестирована и исправлена.
На этапе же старта приложения запускать Е2Е тесты попросту не на чем.
К тому же написание Unit-тестов в некоторых случая помогают ускорить написание самого кода модуля. И во вторых Unit-тесты могут улучшить саму архитектуру приложения в целом и качество написанного модуля в частности. При написании тестов может стать очевидным, что модулем пользоваться просто неудобно.
Поэтому на мой взгляд ответом на вопрос «С чего начинаются тесты» должно быть — тесты начинаются с момента разрабокти приложения, Е2Е тесты на старте — это просто спецификация, за реализацией дело не стоит. Unit-тесты на старте — вполне оправданы. Поэтому стоит их начинаться писать одновременно, спецификации — аналитики или тестировщики, unit — разработчики
С чего начинаются тесты