Комментарии 7
Сначала подумать над сценариями, потом провести вдумчивое ревью юнит тестов на предмет соответствия и проверки бизнес-логики - это вполне себе времязатратный white box testing. Вопрос будет ли хватать времени на классическое чёрноящичное тестирование у тестеров, если все так будут делать?
Привет, спасибо за вопрос! Да, такой подход действительно требует большого количества времени. Проработка тестов в начале частично сократит конечную работу и, по моему опыту, уменьшит количество итераций тестирования т.к. большинство корнер-кейсов уже будет предусмотрено.
Но в общем и целом времени это займет больше, поэтому важно договориться с командой. Выгода по времени будет в перспективе — благодаря высокому покрытию автотестами, будет меньше трудозатрат на поддержку качества, но посчитать это довольно сложно.
Тоже использую аналогичный подход, построить нормальную пирамиду - это бесценно. А касательно затрат времени, до момента применения подобных практик приходилось автоматизировать все проверки на уровне API (я в основном по микросервисам). Мой опыт говорит, что протестировать многообразие входных данных, а так же сделать это при необходимости с использованием моков и других инструментов, значительно быстрее на уровне юнитов/интеграционных тестов, чем пытаться повторить это на вершине пирамиды. И это мы еще не коснулись тех косвенных бонусов которые получает команда за счет такого плотного взаимодействия ее членов.
Но надо признать, что построить в одной команде это не так сложно, а масштабировать такой подход, действительно очень трудозатратно. У нас ушло около года на все трения.
Статья для идеального мира. Аж посмеялся временами
шаг 1 - "нужно объяснить им, что вы хотите от unit-тестов и зачем" - Даже если объяснить и попросить, не всегда разраб напишет юниты.
шаг 2 - "Можно пройти курсы по языку программирования, который используют в команде" - 90% случаев каждый проект написан на разном языке. Если выучить хотя бы 2, то зачем сидеть в тестерах?
шаг 3 - см. шаг 1
Такое ощущение, что статью писал ботан, который сидел пару лет на одном единственном проекте. Да, хотелось бы что бы все процессы соблюдались, но гибкость и умение приспосабливаться к изменениям (а они в нашей сфере часто, через день новые правки от заказчика) важнее, чем стремится к идеальным процессам.
Даже если объяснить и попросить, не всегда разраб напишет юниты.
И, в нормальной команде, не пройдет code review
90% случаев каждый проект написан на разном языке. Если выучить хотя бы 2, то зачем сидеть в тестерах?
В нормальной команде - нет. Может быть есть легаси (например у нас была Java в старых и Kotlin в новых проектах). Но такого зоопарка как "каждый проект на своем языке" в серьезных системах, как правило, не бывает. Слишком сложно это сопровождать.
Мне жаль, что ваш опыт работы заключается в таких проектах, как вы описали.
Если в команде нет требований к минимальному покрытию unit-тестами, и коммуникация развита так, что нет возможности донести необходимые для поддержания качества требования, то вам стоит начать с базовых процессов построения качества в команде. Удачи вам в этом!
Как QA-инженер может влиять на unit-тесты