Открыть список
Как стать автором
Обновить

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

Аналитик то системный тест напишет. Только документ будет называться "требования к системе". И возможно "сценарии использования". А вот сколько раз придется автоматизацию этого теста переписывать до конца системы? как бы не чаще, чем выкидывать юнит тесты. Так как если АПИ внешних систем худо бедно зафиксирован и их состав почти не меняется, то пользовательский интерфейс будет переделан миллион раз. А во вторых, половина системных тестов не пройдет до 80% реализации системы. И проку от того, что они были написаны первыми, если они все время красные?

Есть только один маленький нюанс: начать писать юнит-тесты я, как разработчик, могу сразу с началом разработки системы. А начать писать системные тесты я не могу никогда, потому что это требует навыков, которых у меня нет (и получать которые я и не планирую). Поэтому выбора "системные тесты или юнит-тесты" у меня не стоит. У меня стоит выбор "юнит-тесты или никаких тестов", или, при везении, "юнит-тесты или интеграционные тесты".


Поэтому я все еще выбираю писать юнит-тесты.

Можете привести пример системы, которую Вы разрабатывали, но не знали, как покрыть её системными тестами? Может быть на этом примере я смогу убедить Вас, что системные тесты — это не так сложно, как кажется.
Можете привести пример системы, которую Вы разрабатывали, но не знали, как покрыть её системными тестами?

Любое веб-приложение, требующее стабильной БД. Особенно если это крупное веб-приложение, на которое я пришел спустя лет пять после его запуска, и где мне надо поправить небольшой кусок в ядре.


(или вот лямбды в AWS, и вообще serverless functions, очень неудобно и дорого покрывать системными тестами)

Для большей конкретики давайте возьмём в качестве примера классическое веб-приложение «todo-list», которое хранит список задач в БД. Подойдёт?
Я бы мог составить статью, в которой описывается процесс разработки такого веб-приложения в стиле TDD. То есть сначала пишутся системные тесты, а потом — реализация. Вам было бы интересно почитать такую статью?
Для большей конкретики давайте возьмём в качестве примера классическое веб-приложение «todo-list», которое хранит список задач в БД. Подойдёт?

Нет, оно слишком простое.

Довольно странные суждения и выводы. Вы приводите иллюстрацию пирамиды, но совершенно не понимаете сути образования этой пирамиды и пытаетесь трактовать ее по–своему, на основе чего даёте ответ на вопрос заведомо некорректный.

Пирамида — это свойство которое образуется самостоятельно при разделении тестов на цели и зоны ответственности и выражено оно соотношением стоимости к качеству, меньше стоимость и выше качество. Не нужно пытаться собственноручно выстроить данную пирамиду, руководствуясь лишь тем что UI-тестов должно быть меньше, чем Unit-тестов — ничего хорошего из этого не выйдет.

Ваш вопрос «С чего начать?» некорректен тем, что вы оперируете совершенно разными видами тестов, цели которых очень сильно отличаются. И каждый вид тестов не должен пересекаться с другими и уж тем более нести ответственность за других. Если писать только E2E-тесты, то мы можем отвечать только за то что определённый сценарий действий работает, но не за корректность всех данных по пути этого сценария. Например, если вдруг каким-то образом у вас E2E-тесты начали нести ответственность и за данные на каждом шаге, то спешу порадовать — вы начали писать тесты других видов за счёт E2E-тестов, что само по себе дорогое удовольствие и противоречит пирамиде с которой вы начали. Любые тесты писать необходимо тогда, когда дело доходит до зоны ответственности, которую необходимо покрыть тестами, а не когда вздумается.

Просто для любого нового проекта это абсолютно нормальная ситуация — в какой-то момент понять, что изначальная архитектура или затея вышла не слишком удачной — и что нужно всё (или практически всё) переделывать.

Это абсолютно не нормальная ситуация, это уже вопрос к компетентности и уровню команды, и говорит только о том что с ней явно что-то не так. Использовать это как аргумент против Unit-тестов совершенно глупо. Каждый ответственный разработчик каким-либо образом проверяет работоспособность своего кода, вопрос только лишь в том каким образом? Поднимает целиком всю систему на каждый чих и ручками проверяет? Что-то сильно дорого выходит, не так ли? Это еще ладно если такая возможность вообще есть, а если ее нет? Интересно было бы узнать как обойтись в таком случае без Unit-тестов.
Вкину свое мнение, как автотестровщик:
Крайне «больно» писать системные тесты на ранних этапах разработки какого-нибудь функционала. Он часто меняется и не стабилен, поэтому часто приходится оставлять работу на половину, а потом возвращаться к дописыванию этих тестов после того, как фича будет более менее дописана, протестирована и исправлена.
На этапе же старта приложения запускать Е2Е тесты попросту не на чем.
К тому же написание Unit-тестов в некоторых случая помогают ускорить написание самого кода модуля. И во вторых Unit-тесты могут улучшить саму архитектуру приложения в целом и качество написанного модуля в частности. При написании тестов может стать очевидным, что модулем пользоваться просто неудобно.
Поэтому на мой взгляд ответом на вопрос «С чего начинаются тесты» должно быть — тесты начинаются с момента разрабокти приложения, Е2Е тесты на старте — это просто спецификация, за реализацией дело не стоит. Unit-тесты на старте — вполне оправданы. Поэтому стоит их начинаться писать одновременно, спецификации — аналитики или тестировщики, unit — разработчики
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
testo-lang.ru
Численность
2–10 человек
Дата регистрации

Блог на Хабре