Всем привет!
Я готовлюсь к конференции SeleniumCamp, и мне нужно собрать немножко статистики. Помогите мне пожалуйста, ответьте на один вопрос.
Всем известно такое понятие, как пирамида тестирования. Согласно этой концепции, доля юнит-тестов в системе должна быть очень большой, а доля всех остальных тестов - маленькой. И вроде бы всем очевидны причины (юнит-тесты быстрые и надёжные), но во многих компаниях ситуация совсем другая. Юнит-тестов мало или нет совсем, а браузерных/интеграционных тестов много.
Внимание, вопрос: какая пирамида у вас в компании? Если юнит-тестов нет или мало, то почему? Почему не используете классическую пирамиду?
“Почему” отвечается очень просто: юнит-тесты начинают цениться, когда их уже приличное кол-во. Если солидный кусок кода продукта тестится за несколько минут, это радует абсолютно всех. Если можно внести изменения в код и за минуту-другую понять, что ничего не сломал - это очень мотивирует.
Но до такого состояния ещё надо дойти. И на этом пути крайне много отмаз. И все эти нежелания/неумения и т.д. всегда формулируются наружу одинаково: “компания продаёт не юнит-тесты, а продакшн-код”. И это правда - лучше продавать хоть что-то, а потом фиксить и саппортить, чем сделать идеальный продукт за долгое время (и время измеряется ещё и в зарплатах), и столкнуться с более дешёвыми конкурентами, написавшими что-то низкого качества, но первыми на рынке.
Что касается статистики - сказать трудно Средняя температура по больнице - где-то между pyramid pattern и icecream anti-pattern На некоторых небольших проектах - высокое покрытие юнит-тестами, весь продукт тестится за 1-2 минуты плюс пару раз в день акцептанс-тесты по 20 минут. А есть продукты (обычно большие и/или старые), где юнит-тестов относительно мало, большую роль играют долгие тесты, а то и ручной просмотр (да и есть вещи, которые надо бы посмотреть косым взглядом перед релизом ибо не всё автоматизируется (“не съехало ли форматирование”, например)). На таких продуктах девелоперы не любят вносить изменения (но такие продукты уже имеют имя и положение на рынке). Чтобы внедрить автотесты надо или менять код продукта (SOLID) - а это страшно, или покупать что-то вроде TypeMock, что требует непонятных начальству затрат денег и времени, да ещё и поддерживает плохие практики написания кода.
Примечание: большинство проектов - не вэб, это системное администрирование, администрирование БД, и подобное. Максимум “вэба” - админские вэб-консоли и шарпойнты, кое-где вэб-GUI продукта.
Могу раскрыть статистику по одному из моих проектов: uiautomation. Где-то в ноябре, в середине, перешёл на DI/IoC. На тот момент юнит-тестов, естественно, не было (ненаследуемые классы, статические классы). Как только всё обернул и подключил DI, начал писать юнит-тесты. И на новый функционал, и на старый. На сейчас это 600 юнит-тестов (22-23 секунды) и 500 акцептанс (20 минут, раздражает невероятно). Акцептанс-тесты почти не добавляю: как было 400 год или два назад, так вот к пятистам только и подтянулось. Планы - несколько тысяч юнит-тестов и 2 минуты (иногда запускать акцептанс). Сроки - понятное дело, хобби-проект, но скорость растёт - потому что растёт покрытие, код оптимизируется. Думаю, весной буду близок к желаемому. пруфлинк
Проектов несколько, но автоматизация начинается обычно именно с приемочных функциональных тестов, потому что:
это наглядно - проще обосновать необходимость, показав результат
отвлечь одного из тестировщиков на написание автотестов морально проще (для заказчика), чем разработчиков
То, что это занимает много времени и не решает многих проблем заказчику не понятно. Оплачивать время на написание юнит-тестов никто не будет. Тут нужна дисциплина и инициатива именно со стороны разработки.
Поэтому, мне кажется возможны следующие ситуации:
если разработчики уже умеют разрабатывать с использованием юнит-тестов, то новый проект скорее всего будет иметь правильную пирамиду тестирования
если разработчикам надо сначала разобраться с тем как писать юнит-тесты, использовать моки/стабы, как писать тестируемый код и т.д., то тут требуются доп.вложения, на которые заказчик не пойдёт
если продукт старый и не имеет юнит-тестов, то здесь ситуация аналогичная п.2, даже если разработчики имеют опыт юнит-тестирования
Во 2 и 3 случаях автоматизация тестирования на проекте развивается значительно дольше
У нас пирамида классическая (много unit, мало долгих тестов), и збоку не-функциональные тесты.
Делаем свой продукт в стартапе, мы отчасти себе же заказчики.
“Почему?” - т.к. “шипать” быстрее получается.
Проект большой и старый. Начинал писатся без учета юнит\интегрейшн тестов. Сейчас архитектура не позволяет быстро и легко писать юнит тесты без кучи моков и заглушек - низкая модульность продукта.
Разработчики пишут, но довольно медленно и вяло.
Больше всего сейчас информации приходит от UI и ручного тестирования.
Привет всем заинтересованным!
Наконец-то появилось видео моего доклада, где я рассказываю про “правильное” тестирование. В том числе про пирамиду тестирования.
testomat.io управление авто тестами
Средняя температура по больнице - где-то между pyramid pattern и icecream anti-pattern