PRO автотесты

сегодня на работе получил ачивку за 10 лет работы в Яндексе 😊

Каким образом автотесты приносят пользу? Кажется, что ответ очевиден: автотесты находят баги.

Но если так, то получается, что польза от автотестов возникает только тогда, когда они упали, и эта польза заключается в информации о найденном баге. Получается, что все успешные запуски автотестов бесполезны?

На самом деле, нет. Успешные и неуспешные автотесты одинаково полезны, если они показывают состояние вашего проекта, а не только наличие багов. Если ваши автотесты надежны и вы доверяете их результатам, то успешный прогон автотестов будет означать гарантию, что с проектом всё хорошо. Эта информация, полученная от автотестов, позволит вам принимать решения в процессе разработки, сэкономит команде время и нервы.

Посмотрите на автотесты в своем проекте и задайте себе вопрос: какую информацию вы получаете в результате их прогона. Полезна ли она?

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

Многие путают слова "простой" и "лёгкий".

Антоним слова "простой" — слово "сложный". Эти понятия обозначают количество элементов, из которых состоит что-либо. Например, когда кто-то говорит "сложная система", то сразу представляется система из большого количества частей с запутанными связями. Человеческий мозг плохо обрабатывает сложность (погуглите закон Миллера).

Антоним слова "лёгкий" — слово "тяжелый" или "трудный". Эти слова описывают, сколько усилий нужно приложить, чтобы достичь чего-то. Если "простота" — это объективное понятие (количество элементов в системе), то "лёгкость" — это относительное понятие, т.к. количество труда зависит в том числе от того, кто его прилагает.

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

Не нужно далеко ходить за примерами. Все мы запускали короткую команду npm i, которая выкачивает гигабайты пакетов в папку node_modules.

Когда видите новый модный инструмент, который так легко использовать, задумайтесь, не усложнит ли он на самом деле ваш проект. Посмотрите старый, но актуальный доклад на эту тему: "Simple Made Easy" - Rich Hickey (2011)

Да пребудет с вами сила!

Сегодня опубликовали первый кусок программы осенней HolyJS и там есть мой воркшоп про модульные тесты!
https://holyjs.ru/talks/49b78b08a81445db963490d51be07131/

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

Мне попалась статья Мартина Фаулера об этом. Он говорит, что важен не размер, а изоляция модуля. Тестируемой сущностью unit-тестов может быть фрагмент приложения любого размера. Главное — чтобы он был изолирован от внешних зависимостей.

Откуда возникло мнение о том, что unit-тесты могут проверять только что-то маленькое? Кажется, причина в том, что многие приложения имеют внутри запутанные связи и их разработчики могут изолированно создать в тестах экземпляры только самых маленьких модулей.

В двух командах, где я работал, мы провели рефакторинг приложения, чтобы упорядочить зависимости модулей. В результате мы научились создавать экземпляры фрагментов приложения любого размера и писать на них unit-тесты. Оказалось, что это производительный и стабильный инструмент автоматизации тестирования. Большинство тестовых сценариев переехало в модульные тесты. Суммарное время прогона тестов сократилось с часов до минут, а количество ложных срабатываний — уменьшилось до нуля.

Попробуйте этот подход на своем проекте!

Привет! Это канал про автотесты.

Меня зовут Дима Андриянов, я работаю в веб-разработке больше 20 лет. 10 из них писал бэкенд на C#, потом еще 10 лет — фронтенд в Яндексе. Сейчас руковожу командой разработчиков в Яндекс 360.

Кажется, у меня большой опыт в автотестах:
- я организовывал автоматизированное тестирование в нескольких подразделениях Яндекса,
- с 2017 года читаю лекцию по автотестам в Школе разработки интерфейсов (и был человеком, который инициировал появление этой темы в учебной программе),
- рассказываю про автотесты на конференциях.

Во многих командах автотесты воспринимаются не как полезный инструмент, а как дополнительная нагрузка на разработчиков. Разработчики пишут множество тестов, но получают от них мало пользы. Так происходит потому, что они упускают из виду некоторые важные вещи, связанные с автотестами.

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

Channel created