|
|
@@ -0,0 +1,67 @@
|
|
|
+# **Unit-тестирование**
|
|
|
+
|
|
|
+# **Пирамида тестирования**
|
|
|
+
|
|
|
+
|
|
|
+Чем шире уровень, тем больше тестов. Хорошее приложение должно иметь минимальное кол-во ручных тестов. Они дорогие и неэффективные. Если у вас не так, то ваш процесс проверки качества нездоровый.
|
|
|
+Если вам кажется, что тестировщик должен только тестить руками функционал перед релизом или писать автотесты, то вы не работали с хорошим тестировщиком.
|
|
|
+Ручное тестирование не требует особых навыков и почти любой человек в команде это может выполнить.
|
|
|
+Хороший тестировщик учит и менторит всех в команде как следить за качеством.
|
|
|
+В большинстве случаев ручное тестирование — огромная трата денег и времени. Почти любой тест, допускающий автоматизацию, должен быть автоматизирован.
|
|
|
+Это касается модульных, приемочных, интеграционных и системных тестов .
|
|
|
+Дорогостоящую операцию, как ручное тестирование, следует оставить для ситуаций, в которых необходимо человеческое суждение.
|
|
|
+Например, если нужно проверить эстетику графического интерфейса, провести исследовательское тестирование или субъективно оценить простоту взаимодействия .
|
|
|
+
|
|
|
+# **Недостатки e2e и интеграционных тестов**
|
|
|
+
|
|
|
+В клиентских приложениях об юнит тестах почти забывают. Выделяя ресурсы только на UI тесты. Но это неправильно и не всегда полезно.
|
|
|
+Автоматизированные тесты не должны осуществлять проверку бизнес-правил через пользовательский интерфейс. (c) Роберт Мартин
|
|
|
+Это очень распространенная проблема, когда клиентские приложения проверяют корректность бизнес-логики через UI пользователя. Почему это плохо?
|
|
|
+Повышается хрупкость теста. Бизнес-логика никак не зависит от цвета кнопки или дизайна. Это лишь косметический эффекты, что зависят от платформы.
|
|
|
+Будь у меня андроид, веб или айфон, то ни одно из устройств не должно сломать бизнес-логику. Такие тесты в будущем часто будут флаковать, а в будущем игнорироваться
|
|
|
+Некоторая бизнес-логика не зависят от View слоя или имеют его по-минимуму.
|
|
|
+Дорого для корнер-кейсов. Создавать e2e или компонентные тесты дорого по времени для всех состояний. Часто пишут только один успешный сценарий
|
|
|
+Долгий запуск других тестов. Обычно е2е запускаются рано утром и могут достигать 20-40 часов ожидания.
|
|
|
+Часто дорогие тесты детектят только факт падения, но не дают причины.
|
|
|
+
|
|
|
+# **Чем полезны unit-тесты**
|
|
|
+
|
|
|
+Модульное тестирование (unit testing) — тесты, задача которых проверить каждый класс системы по отдельности.
|
|
|
+Желательно, чтобы это были минимально делимые кусочки системы, например, модули. Unit-тесты — это тесты для одного класса.
|
|
|
+Такие тесты используют для тщательной проверки сложной логики и алгоритмов, инкапсулированных в одном классе.
|
|
|
+ Желательно, чтобы у таких классов не было изменяемых зависимостей.
|
|
|
+Зачем нужны юнит-тесты?
|
|
|
+Цель — обеспечение стабильного роста программного проекта. Ключевым словом здесь является «стабильный».
|
|
|
+В начале жизни проекта развивать его довольно просто. Намного сложнее поддерживать это развитие с прошествием времени.
|
|
|
+
|
|
|
+
|
|
|
+Основной смысл модульного тестирования заключается в том, чтобы избежать накапливания ошибок в будущем, а также исключить регрессию уже отлаженных модулей.
|
|
|
+Например, у вас есть в целом готовое приложение, к которому необходимо добавить несколько новых функций или процессов.
|
|
|
+
|
|
|
+# **Свойства идеальных тестов**
|
|
|
+
|
|
|
+защита от багов. Чем больше кода в проекте, тем выше шанс поймать баг. Хороший юнит-тест — лучшая защита от багов.
|
|
|
+Чтобы понять насколько код хорошо защищен нужно оценить:
|
|
|
+объем кода, выполняемого тестом
|
|
|
+сложность этого кода
|
|
|
+важность этого кода с точки зрения бизнес-логик
|
|
|
+Как правило, чем больше кода тест выполняет, тем выше вероятность выявить в нем баг
|
|
|
+устойчивость к рефакторингу. Эта устойчивость определяет, насколько хорошо тест может пережить рефакторинг тестируемого им кода без выдачи ошибок.
|
|
|
+Иначе говоря, тест не должен ломаться при улучшении кода.
|
|
|
+Нет привязанности к деталям имплементации. Избежать хрупкости в тестах и повысить их устойчивость к рефакторингу можно только одним способом — отвязав их от деталей имплементации тестируемой системы.
|
|
|
+Тесты должны находиться как можно дальше от внутренних механизмов кода и проверять только конечный результат.
|
|
|
+быстрая обратная связь является одним из важнейших свойств юнит-теста. Чем быстрее работают тесты, тем больше их можно включить в проект и тем чаще вы их сможете запускать.
|
|
|
+простота поддержки — оценивает затраты на сопровождение кода. Метрика состоит из двух компонентов:
|
|
|
+Насколько сложно тест понять. Этот компонент связан с размером теста. Чем меньше кода в тесте, тем проще он читается.
|
|
|
+Насколько сложно тест запустить. Если тест работает с внепроцессными зависимостями, вам придется тратить время на то, чтобы поддерживать эти зависимости в рабочем состоянии
|
|
|
+Возможно, чтобы идеальный тест выполнял требования всех пунктов? К сожалению, создать такой тест невозможно
|
|
|
+
|
|
|
+# **Когда не стоит проводить unit-тестирование**
|
|
|
+
|
|
|
+Модульное тестирование — не универсальный инструмент проверки программного продукта. В некоторых ситуациях оно лишь отнимет время и силы, не показав значимого результата, например:
|
|
|
+при тестировании сложных и разветвленных алгоритмов, таких как красно-черное дерево, придется разработать большое число тестов, что существенно усложнит и замедлит проверку;
|
|
|
+отсутствии четких результатов — например, в математическом моделировании природных процессов, настолько сложных, что их «выход» невозможно спрогнозировать, а можно только описать в виде интервалов вероятных значений;
|
|
|
+тестировании кода, взаимодействующего с системой, — например, модуля, связанного с портами, таймерами и другими «нестабильными» компонентами, от которых его сложно изолировать;
|
|
|
+проверке всего приложения — модульное тестирование не покажет ошибки интеграции, баги ядра и другие аспекты, не относящиеся непосредственно к конкретному модулю;
|
|
|
+недостаточной квалификации самого разработчика и низкой культуре программирования, так как модульное тестирование работает только при строгом соблюдении технологии, постоянном отслеживании всех вносимых в модуль изменениях.
|
|
|
+Unit-тестирование окажется бесполезным и при проверке максимально простого кода. Точнее, оно сработает и покажет правильный результат, но сил на написание теста уйдет больше, чем на «ручной» анализ модуля.
|
