В своей работе я постоянно использую unit-тесты. А вы? По моему опыту, большинство программистов – очень редко. Проводя собеседование с кандидатами на вакансии в моей команде, я всегда задаю вопрос: «Есть ли у вас опыт тестирования?». И чаще всего слышу в ответ: «Нет». А если спросить, почему, то самым распространенным ответом будет: «Мне заказчик не дал это сделать».

Такой подход меня удивляет. Разве вы будете указывать строителю, какую марку бетона выбрать для постройки дома? Или автомеханику – какую деталь двигателя ремонтировать, а какую нет, если в машине мотор забарахлил? Вряд ли, ведь это серьезные технические вопросы, решение которых надо доверить профессионалу. У профессионала есть необходимые навыки и инструменты, которые позволяют ему решить проблему быстрее и дешевле.

Зачем считать деньги

В Гражданском Кодексе есть понятие «экономия подрядчика за счет опыта и знаний». Его смысл в том, что работу выполняет профессионал, который знает, как оптимизировать процесс, как сделать лучше, но при этом дешевле. И разработчики как профессионалы должны выдавать заказчику лучшие решения за наименьшие деньги.

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

Логика тут простая: бизнесу – тем самым клиентам, которые заказывают нам разработку ПО для своих компаний, – на самом деле нужен вовсе не софт. Бизнесу нужны деньги, выгода, которую этот софт принесет.

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

Разработка ПО – вообще не самая дешевая часть бизнеса, но некачественный софт может привести к большим потерям. Даже простой оборудования ведет к упущенной выгоде, а проблемы с ПО могут привести к миллионным потерям. Поэтому разработчик как профессионал должен быть уверен в качестве своего продукта и гарантировать это своему клиенту. А ведь именно качество продукта – важнейший показатель. И заказчик должен знать, что это качество можно измерить и быть в нем уверенным. А как именно – это уже задача программиста.

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

Какой тест выгоднее

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

Unit-тест – тестирование production юнитов. Под юнитами я понимаю программные единицы, в зависимости от языка представленные классами, функциями, реже файлами. При использовании TDD подхода тестирование изначально вплетено в процесс разработки продукта. На проекте могут использоваться тысячи таких тестов для проверки отдельных частей кода. У них отличный показатель скорости – весь набор тестов можно выполнить за секунды. Это самые дешевые тесты.

Интеграционный тесты – тестирование 2х-3х или больше юнитов вместе. Таких тестов на проекте могут быть сотни или тысячи, в зависимости от программиста. Скорость – секунды или минуты на весь набор тестов. Стоимость выше, чем у юнит-тестов.

Acceptance-тесты имитируют действие пользователя с программой. Требуют подготовки эксплуатационной среды, поэтому они сложные и дорогие. Количество на проекте – обычно делается один тест на бизнес историю. Скорость работы – обычно от десятков минут до нескольких часов на весь набор тестов.

Самое дорогое и сложное – ручное тестирование. Надо нанять человека, обучить его, создать и дать ему карту бизнес-истории, чтобы он по ней тестировал новое ПО. На такое тестирование уходит несколько дней на весь набор тестов.

Любой тип тестов требует подготовки, а также определенного вложения денег. И чтобы получить экономию (а значит, выгоду), надо прежде всего учитывать скорость тестирования и сложность его запуска. Если на проекте нет автоматических тестов, то остается один выход – ручное тестирование, самое дорогое и медленное.

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

Что касается разных типов автоматического тестирования, то надо учесть еще три важных аспекта.

Прежде всего, это надежность – насколько тест легко «сломать» (этот показатель у unit-тестов самый лучший).

Затем окружение, которое необходимо для выполнение тестов. Unit-тесты очень просты, они сами создают окружение вокруг тестируемого юнита. Интеграционные тесты нуждаются в сервисе, который должен быть установлен, запущен и т.д. Acceptance-тесты требуют подготовки, так как приложение должно работать в своей среде.

И наконец – покрытие (test coverage). Unit-тесты имеют хорошее покрытие, используются на протяжении всего проекта. Интеграционные тесты обычно используются на определенных частях проекта, то есть покрывают программу не полностью. Покрытие у аcceptance-тестов хуже – это связано со сложностью их написания и запуска, чаще всего они покрывают основные бизнес-кейсы, это 20-40% от общего объема проекта.

Заключение

Итак, получается, что по всем показателям этого краткого сравнительного анализа лидируют unit-тесты. В своей практике чаще всего я использую именно их, это дает достаточное качество. Если требования к качеству возрастают, то мы переходим к аcceptance. Использование интеграционных тестов зависит от заказчика, который может захотеть протестировать определенные части проекта.

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