что такое модульное тестирование
Unit-тестирование в сложных приложениях
Ни один разработчик в здравом уме и трезвой памяти при разработке сложных приложений (> 100K LOC, например) не станет отрицать необходимость использования тестирования вообще и модульного тестирования (unit tests) в частности. Это так же верно, как и то, что каждый разработчик постарается исключить бессмысленную работу из творческого процесса создания приложения. Где же та грань, которая отделяет необходимость от бессмысленности, если мы говорим о модульном тестировании в контексте сложных приложений? Пару своих соображений по этому поводу я изложил под катом.
Назначение
Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
Все как бы понятно. Есть 5 строчек кода:
Есть юнит-тест для него (уже 10 строк, но это нормально для юнит-теста, когда количество строк в тесте превышает количество строк тестируемого кода):
Тест позволяет проверить логику работы кода и обнаружить ошибку в случае, если что-то или кто-то эту логику нарушил. Так как модульные тесты проверяют код отдельно от всего приложения, то они является очень простыми и очень быстрыми, и способны за очень короткое время оценить «здоровье» значительной части кода в разработке.
Модульные тесты сами по себе не гарантируют правильность функционирования всего приложения, но являются первым, базовым этапом в списке тестов:
(картинка взята из интернетов исключительно за свою треугольную форму и послойное перечисление некоторых типов тестирования; цифры процентов и прочие детали — несущественны в контексте изложенного;)
Тривиальная тривиальность
«… писать тесты для каждой нетривиальной функции или метода.«
С кодом, который имплементирует логику согласно заданной спецификации, все понятно. А что делать с кодом, где этой самой логики нет? Например, с акцессорами в DTO-like классах?
Сетевой разум относит такие случаи к тривиальным, несмотря на ненулевую вероятность поиметь в коде ошибку типа:
Вероятность подобной ошибки сильно повышается при массовом применении в коде прогрессивной техники «Find&Replace», а желание применить прогрессивную технику возрастает с ростом проекта и более полным погружением в детали предметной области.
Компромиссным вариантом между бессмысленностью и необходимостью может быть обращение к акцессорам при подготовке данных для тестирования других, менее тривиальных классов (таких, как сервисы), в которых используются DTO-like объекты, или проверять через assert’ы результат по возвращении:
Хотя в данном случае нарушается принцип изоляции тестируемого кода от остального кода приложения. Ну, на то он и компромисс, чтобы из двух очень хороших вариантов выбрать третий, не очень плохой.
Нетривиальная тривиальность
Все объектно-ориентированные разработчики рано или поздно натыкались на аббревиатуру SOLID (кто не натыкался — самое время), в которой первая буква «S» соответствует SRP — «класс должен иметь только одну обязанность«. Методичное и последовательное применение этого принципа приводит с одной стороны к упрощению кода отдельного класса, а с другой — к росту количества классов и связей между ними. Для преодоления проблемы роста с успехом используется модульный подход, многоуровневая архитектура и инверсия управления. В чистом остатке имеем сплошной профит в виде «упрощения кода отдельного класса«, вплоть до вот таких реализаций отдельных методов:
Тестирование подобного кода опять балансирует на грани между бессмысленностью и необходимостью — по сути тест сводится к созданию заглушек/моков и проверке, что будут вызваны соответствующие методы в соответствующем порядке. Точно такого же эффекта можно добиться гораздо быстрее, если делать контрольную копию файла с исходным кодом и сообщать при тестировании обо всех отклонениях текущего кода от контрольной копии.
Коллега Dimitar Ginev рекомендует разделять в подобных случаях код по двум категориям классов (orchestrator и decision makers) и покрывать тестами код только второй категории.
Code coverage
Замечательной метрикой для оценки качества кода явлется % покрытия кода тестами. Этот процент можно рассчитать как для отдельного файла с исходным кодом, так и для всей кодовой базы проекта (например, покрытие модульными тестами Magento 2.1.1). Покрытие кода дает возможность визуально оценить проблемные области в разрабатываем исходном коде и должно стремиться к 100% покрытию значимого кода. Причем, чем сложнее разрабатываемое приложение, тем больше значимого кода в нем, и большее значение начинает иметь стопроцентность покрытия. Модульные тесты являются очень хорошими кандидатами для использования их результатов при расчетах этой метрики опять таки в силу своей независимости (друг от друга и от остального, нетестируемого в данный момент кода) и скорости выполнения.
Покрытие всего кода в проекте можно довести до 100% двумя путями:
Первый способ подразумевает, что тесты должны будут создаваться также и для каждой тривиальной функции или метода, что увеличивает бессмысленность. Второй способо чреват пропуском покрытия тестами нетривиального кода, что отрицательно сказывается на необходимости.
Так где же баланс?
Так как сообщество сходится во мнении, что нет нужды в тестировании тривиального функционала, то вполне очевидно, что чем проще код или гениальнее разработчики, тем меньше поводов создавать тесты вообще и модульные тесты в частности. И наоборот, чем сложнее код или посредственнее разработчики, тем поводов больше. Т.е., если вы в одиночку разрабатываете проект на 100К строк кода, то вы вполне можете обойтись без тестов вообще, но как только к проекту подключается еще один разработчик (не такой гениальный, как вы), то необходимость создания тестов резко возрастает. А если этот разработчик еще и junior, то тесты становятся жизненно важны, т.к. даже ваша гениальность может спасовать перед тем энтузиазмом, с которым junior вносит ошибки в ваш любимый код.
Если на начальном этапе разработки вполне можно исключить из модульного тестирования тривиальный код (акцессоры и оркестраторы), то чем больше становится проект и чем больше народа работает над проектом, тем меньше в нем остается тривиального кода. В предельном случае, когда код общедоступен (т.е., pull request может прийти от какого-нибудь скучающего охранника автостоянки, решившего в эту ночь побыть программистом), модульными тестами должна быть покрыта каждая строка кода, даже самая тривиальная.
Что такое модульное тестирование
В этой статье вы найдете следующую информацию:
В моделях разработки SDLC, STLC, V Model модульное тестирование – это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование – это метод тестирования WhiteBox, который обычно выполняется разработчиком. На деле же из-за нехватки времени или халатности разработчиков, иногда модульное тестирование приходится проводить QA инженерам.
Зачем нужно модульное тестирование?
Отсутствие модульного тестирования при написании кода значительно увеличивает уровень дефектов при дальнейшем (интеграционном, системном, и приемочном) тестировании. Качественное модульное тестирование на этапе разработки экономит время , а следовательно, в конечном итоге, и деньги.
Ниже перечислены методы покрытия кода:
Пример модульного тестирования: фиктивные объекты
Модульное тестирование основывается на создании фиктивных объектов для тестирования фрагментов кода, которые еще не являются частью законченного приложения. Подставные объекты заполняют недостающие части программы.
Например, у вас может быть функция, которая нуждается в переменных или объектах, которые еще не созданы. В модульном тестировании они будут учитываться в форме фиктивных объектов, созданных исключительно для целей модульного тестирования, выполненного в этом разделе кода.
Разработка через тестирование (TDD)
Модульное тестирование в TDD включает в себя широкое использование платформ тестирования. Каркас модульного тестирования используется для создания автоматизированных модульных тестов. Структуры модульного тестирования не являются уникальными для TDD, но они необходимы для него. Ниже некоторые преимущества TDD:
Рекомендации по модульному тестированию
Статья подготовлена на основе материалов сайта guru99.com
Что такое юнит-тесты и почему они так важны
Бывает, кодишь 10 минут, а дебажишь 2 часа. Чтобы такого не случилось, пилите юнит-тесты. Михаил Фесенко рассказал, как их правильно готовить.
Фесенко Михаил, можно просто Фес. Разработчик, раньше работал системным администратором, пишет на чём скажут, но пока писал на PHP, Go, Python, Bash. Сейчас работает в «Яндекс.Облаке», до этого работал во «ВКонтакте». Любит жену, кино и снимать видео =)
Юнит-тест (unit test), или модульный тест, — это программа, которая проверяет работу небольшой части кода. Разработчики регулярно обновляют сайты и приложения, добавляют фичи, рефакторят код и вносят правки, а затем проверяют, как всё работает.
Тестировать систему целиком после каждого обновления — довольно муторно и неэффективно. Поэтому обновлённые или исправленные части кода прогоняют через юнит-тесты.
Особенности юнит-тестов
На практике используют разные тесты — их разделяют по уровню абстракции с помощью пирамиды Майка Кона :
Чем выше тест в пирамиде, тем больше частей программы он затрагивает. Высокоуровневые тесты «ближе к бизнесу»: они проверяют бизнес-логику и пользовательские процессы. А те, что внизу пирамиды, помогают найти проблемы в отдельных частях кода. Например, какую-нибудь функцию, которая генерирует имя файла.
В отличие от них, юнит-тесты нужны в следующих случаях:
Некоторые программисты пишут только юнит-тесты, а на интеграционные или E2E-тесты жалеют времени. На самом деле нужно покрывать систему всеми видами тестов, чтобы знать, как взаимодействуют друг с другом разные части программы, какие промежуточные результаты они выдают. Но в то же время, если юнит-тесты показывают ошибку, её покажет и интеграционный, и E2E-тест.
Процесс юнит-тестирования
Для юнит-тестирования подключают тестовые фреймворки — они позволяют «мокать», то есть имитировать функции. В коде больших проектов много зависимостей: одна функция вызывает другую и влияет на разные части программы. Но, как правило, достаточно проверить функции «в вакууме», отдельно от остального кода. Для этого и нужен тестовый фреймворк — он моделирует условия, в которых функция А вызывает функцию Б изолированно от других функций.
Простой пример: у нас есть функция на Go, которая получает id бэкапа и возвращает имя бэкап-файла:
Протестируем её с помощью набора входных и выходных данных. Они должны учитывать все ситуации, поэтому не забываем про негативные кейсы — когда программа возвращает ошибку. Вот набор тестовых данных:
В первую очередь я прописал запрещённые данные (-1 и 0) и слишком большое значение (10200300). Когда пользователь их вводит, функция не должна возвращать результат. Вместо этого мы ждём сообщения об ошибке: BAD_ID или BACKUP_ID_TOO_BIG. Когда же функция получает валидный id, она выводит отформатированное имя файла, например Backup#000010.
А вот и код самого теста:
Порой код для тестирования даже больше основного — и это норма. Но иногда всё-таки стоит задуматься, на самом ли деле тест должен быть таким объёмным. Я бы посоветовал покрывать тестами только те фрагменты кода, которые вы планируете менять. Или сложные части, которые, скорее всего, придётся чинить или поддерживать.
Некоторые разработчики мокают всё подряд. Из-за этого тесты становятся хрупкими, а код — сложным и непонятным. На самом деле для юнит-тестирования достаточно лишь немного переписать код, а огромные функции лучше разбить на более мелкие.
В старой хорошей книге «Экстремальное программирование» есть классная мысль: сначала пишите тест, а только потом программу. Это клёвый подход, но не все могут так делать (а кто-то просто не хочет тратить время).
Как покрыть код юнит-тестами
Есть разработчики, которые не проводят модульное тестирование: «Ой, у нас большой проект, и переписать 1000 строк под тесты или замокать их — слишком запарно». На самом деле покрыть код тестами несложно. Вот несколько советов.
Написали код — напишите тест. Я видел много проектов, в которых юнит-тесты писали по принципу «новый код — новый тест». Думаю, это правильный подход, ведь, когда добавляешь в программу что-то новое, она часто ломается. К тому же, если писать тесты сразу, не придётся переворачивать весь код, когда он разрастётся.
Есть более жёсткий принцип: новый код без тестов на ревью не принимается. Конечно, он работает, если сроки не горят, — иначе программист рефакторит или покрывает его тестами позже.
Используйте тестовый фреймворк. В тестировании не нужно изобретать велосипед. Для популярных языков уже есть готовые решения, поэтому достаточно вбить в поиске test frameworks, и вы получите целый список. Вот, например, результат для Python:
Пишите простые тесты. Надо понимать, что происходит с входными данными и какой результат должна вернуть функция. Если непонятно — меняем нейминг и разбиваем функции на более мелкие, избавляемся от зависимостей. Пусть одна функция принимает результат, а другая возвращает. Так проще тестировать.
Допустим, у нас есть такая функция:
Её не нужно прогонять через юнит-тест, потому что тогда придётся мокать process_a, process_b и prepare_output. Тут нужен интеграционный тест, который проверит, как эти компоненты взаимодействуют между собой. Вообще, если код сложно покрывать юнит-тестами, используйте интеграционные — они проверяют общую работу системы, модуля или библиотеки.
Не забывайте про негативные тесты. Это the best practice. Что произойдёт, если передать в программу неправильные данные? Какую ошибку она выведет и выведет ли?
Покрывайте тестами все циклы и if-else. Этот совет касается кода, который нужно поддерживать. Если ему не следовать, на одной из итераций правок вы или ваш коллега просто всё сломаете.
Проверяйте качество тестов. Сделать это поможет мутационное тестирование. Мутационный фреймворк случайно меняет константы и значения в условных операторах и циклах, создаёт копию кода, в которой поочерёдно меняет условия. Например, было >= или было COUNT=3, а стало COUNT=10. Каждая замена тестируется: если код поменялся, а тесты не упали, значит, код не покрыт тестами.
На мутационное тестирование уходит много времени. Можно подключить плагин, который считает code coverage по тесту и выдаёт отчёт. Например, у нас покрыто тестами 43 тысячи строк кода, а 10 тысяч — нет. Значит, code coverage 81%. Но тут важен не только сам процент, но и качество — какие именно фрагменты кода и какими именно тестами покрыты. Например, не всё может быть под юнит-тестами — часть может перекрываться интеграционными.
Обеспечьте достаточный процент покрытия кода. Года три-четыре назад я был фанатиком стопроцентного покрытия. Конечно, безумно круто, когда ты всегда знаешь, что именно сломалось. Но в продакшне этого добиться сложно — да и не нужно. Исключение — маленькие проекты или «жёсткие» команды, для которых полное покрытие в приоритете.
На самом деле, code coverage в 70–90% — уже крутой показатель, но и меньше 70% — тоже плохо. И ещё важный момент: новый код не должен понижать уровень code coverage.
Проверить code coverage можно с помощью coveralls.io:
Coveralls принимает результаты тестов и выдаёт отчёт: показывает процент покрытия и как он изменился с последнего теста.
Не делайте хрупкие тесты. Если тест нестабильный и регулярно падает, его называют хрупким. Его результат может зависеть от дня недели, времени суток, чётности или нечётности запуска. Бывает, две функции работают параллельно и на итоговый результат влияет то, какая из них закончит выполняться первой. Такие функции лучше разбивать на несколько простых и тестировать по отдельности. Мокайте всё что нужно, чтобы сделать тест управляемым, но не переборщите — иначе код будет сложно поддерживать.
Допустим, мы написали юнит-тесты для двух функций. Но не учли, что первая функция сохраняет данные в глобалке, а вторая из-за этого меняет своё поведение. В результате первый тест проходит нормально, а второй падает или ведёт себя странно. А всё потому, что мы не сбросили состояние глобальной переменной.
Следите за скоростью тестов. Тесты должны работать быстро. Если они проверяют кусок кода 10–15 минут — разработчики устанут ждать и отключат их нафиг. Поэтому регулярно проверяйте скорость, ищите узкие места и оптимизируйте тесты. Если есть проблемы, подключитесь через дебаггер — возможно, основной код плохо оптимизирован и искать проблему нужно в продакшне.
Преимущества юнит-тестов
Если у вас ещё остались сомнения, писать юнит-тесты или нет, вот несколько аргументов за. Итак, чем полезны юнит-тесты.
Упрощают работу — находят ошибки, которые вы можете не заметить (меня это много раз спасало). Например, меняешь одну строчку, чтобы поправить логи, а ломается весь код. Благодаря тестам я узнавал об этом ещё до продакшна.
Понятно документируют код. Если вам неочевидно, как работает та или иная функция, можно пройти дальше по коду или открыть юнит-тест. По нему сразу видно, какие параметры принимает функция и что отдаёт после выполнения. Это упрощает жизнь тем, кто работает с чужим кодом.
Помогают ничего не сломать при рефакторинге. Бывает, что код написан непонятно и ты не можешь его отрефакторить, потому что наверняка что-то сломаешь в продакшне. А с тестами код можно смело рефакторить.
Упрощают разработку. Кажется, что юнит-тесты всё усложняют, ведь нужно написать в два раз больше кода — не только функцию, но и тест к ней. Но я много раз убеждался: когда пишешь код без тестов, потом тратишь гораздо больше времени на поиск и исправление ошибок.
Бывает, бац-бац — и в продакшн, а потом понеслось: исправляешь код первый, второй, третий раз. И постоянно вспоминаешь, как тестировать его вручную. У меня даже были файлики с входными данными для таких проверок. Тогда я тестировал программы вручную, по бумажке, и тратил на это уйму времени. А если бы написал юнит-тест, нашёл бы эти баги сразу и не переписывал код по несколько раз.
В коммерческой разработке без юнит-тестов никуда
Сейчас в коммерческой разработке без тестов почти не работают — а в большинстве компаний от разработчиков даже требуют покрывать код юнит-тестами. Везде, где я работал в последние несколько лет, тоже было такое правило. Ведь если в команде кто-то факапит, то может развалиться вся работа — а тестирование как раз защищает от краха.
Современные компании подписывают SLA — гарантируют работоспособность сервиса. Если продукт упадёт, бизнесу придётся заплатить деньги. Поэтому лучше подождать тестов и не катить код, который положит весь продакшн. Даже если сайт или приложение пролежат всего две минуты, это ударит по репутации и дорого обойдётся компании.
Чтобы лучше понять юнит-тесты, изучите тестовые фреймворки вашего языка. А потом найдите крупные open-source-проекты, которые их используют, и посмотрите, как они работают. Можно даже скачать проект и поиграть с тестами, чтобы глубже погрузиться в тему.
Чтобы познать тонкости разработки и тестирования приложений, лучше сразу учиться у практикующих профессионалов. Приходите в университет Skillbox, выбирайте курс и осваивайте программирование под присмотром экспертов.
обложка: Oli Scarff / Staff / GettyImages
Модульное тестирование в современных командах
Для кого эта статья?
Для каких команд это подойдёт?
Я хотела бы показать вам процесс внедрения модульного тестирования для 2-х типов команд. В командах, которые работают по гибкой методологии и в командах, которые выбрали для себя каскадный стиль работы.
Ниже на диаграмме показано схематическое устройство команд по ролям:
Из этой схемы можно заключить то, что проджект менеджер, получая задачи от держателя продукта, согласовывает их со всеми участниками процесса и по результатам включает (или нет) их в спринт.
Чем модульное тестирование отличается от обычного?
Теперь хотелось бы рассказать что же такое модульное тестирование и как это реализовано в нашем случае:
Начну с того, что специалистами модульного тестирования являются эксперты в своих областях (под этим чаще всего понимается конкретная система). Они обладают широчайшим бэк граундом и необходимыми техническими навыками. Каждая система требует своих знаний, где-то это экспертные знания Pl/SQL, где-то конкретных языков разработки, а где-то только многолетний опыт работы с конкретной системой. Мы не затрагиваем front-end системы. Мы стоим на страже систем middle и back уровней.
Наверное ни для кого не секрет, что разработка/доработка любой фичи включает в себя изменения в системах на различных уровнях. Каждый модульный тестировщик проверяет новый функционал только в рамках своей системы. Тестируется код, соответствие контрактов без применения интерфейса. Выборка тестовых данных также происходит не вслепую, а на основе принципа минимального набора данных, покрывающего максимальное количество вариации выходных параметров. Для нас главное функциональная и техническая правильность написанного кода.
Первое отличие модульного тестирования от других видов заключается в том, что мы смотрим в код и ориентируемся на неизменность зафиксированных контактов/выходных параметров. Если они зафиксированы и не нарушаются, то в процессе интеграции систем фича включается без проблем.
И второе — это существенное снижение времени на тестирование доработки за счет экспертизы. Интеграционное тестирование смотрит фичу целиком, мы же рассматриваем ее по частям. Какие задачи решает модульное тестирование? Исходя из всего вышесказанного можно подвести черту и ответить на вопрос: какие же задачи решает модульное тестирование?
Польза внедрения модульного тестирования
После прочтения всего этого возникнет вопрос, а какие плюсы от внедрения модульного тестирования можно получить? Ранее я привела 2 схемы работы команд, и теперь опишу применительно к каждой из них:
Команда, работающая по аджайл методологии. Ниже на схеме приведено место модульного тестирования в команде такого типа:
В данном случае модульное тестирование подключается на поздней стадии разработки, когда происходит фактически уже «вылизывание» кода, а вся основная функциональность разработана. Модульному тестировщику НЕ НАДО начинать в процесс с начала, чтобы глянуть правильно ли выполнена разработка на бэк офисной системе или интеграционной шине.
В аджайл команде все участники процесса до начала разработки знают какие фичи они взяли в спринт и понимают как они должны работать с точки зрения конечного пользователя. В итоге мы приходим к тому, что время, которое необходимо затратить, прежде чем специалист приступит к тестированию, близко к нулю. Нам не нужно писать тест-кейсы (не спешите удивляться как же так, а как же передача знаний и тому подобное), мы сразу лезем в код и приступаем.
После окончания разработки мы получаем, что далее в тестирование задача идет уже проверенной и не содержащей критичных багов (как со стороны разработки, так и со стороны анализа). А что с некритичными? Такие баги встречаются, но крайне редко и обычно они завязаны на очень специфичные тестовые данные. Каждый такой кейс обрабатывается и заносится в вики команды. Но это еще не все плюшки, которые получаются на выходе!
При наличии в команде модульного тестирования автоматизатора (а он у нас есть!), на выходе мы также получаем автоматизированные модульные тесты! Это может быть набор тестов на каком либо выбранном тестовом фреймворке, либо набор скриптов, которые объединены в единый пак и вызываются по требованию/расписанию. Далее эти тесты включаются в некий регресс пак, который содержит в себе и автоматизированные модульные тесты и тесты отдела автоматизации (чуть позже мы рассмотрим, чем они отличаются) и прогоняется перед выводом задач спринта на бой. Что он нам дает думаю ясно и без моих пояснений.
Также допускается, подключение интеграционного тестированию параллельно с модульным тестированием. Пока команда тестирования через фронтовые системы дойдет до middle или back систем, тестирование будет выполнено уже более чем на 70-80%. Т.е. никаких простоев, связанных с необходимостью правки кода, у них не будет. Это что касается аджайл-команды.
Теперь посмотрим как обстоят дела в командах, которые работают по каскадному принципу. Схема с включенным модульным тестированием выглядит так:
Тут мы видим, что интеграционное тестирование начинается после окончания модульного. Это основное и принципиальное отличие от уже рассмотренного варианта. Пока задача не ушла с модульного тестирования, интеграционное тестирование не начинается. Готовятся тестовые сценарии, тестовые данные.
В остальном процесс не меняется, те же данные на выходе и те же плюшки, что и в agile командах.
Чуть выше я обещала поговорить о том, чем же отличаются автоматизированные модульные тесты, от автотестов команды автоматизации. Отличие очень простое и на поверхности. В 99% команда автоматизации автоматизирует не конкретную доработку, а процесс.
Рассмотрим на примере запроса информации по карте через интернет банк. Команда автоматизации пишет кейс на уровне фронта (логин/переход на вкладку/выбрали карту/нажали кнопку запросить баланс) Все мы знаем сколько по времени будет выполняться такой тест. А на выходе мы получим либо есть информация, либо ее нет. В очень редких случаях мы получим понимание в какой системе/каком функционале произошла ошибка.
Что с автоматизированными модульными тестами? Берем тот же пример. Тест написан на интеграционный уровень, которому на вход подается заполненный контракт (вытаскивается из фронтовой системы), далее происходит трансформация, вызов системы источника, обработка результатов и формирование ответа для системы приемника. В каждой точке стоит проверка. Осталось проверить, а точно ли все что надо вернула система источник? Далее вы знаете решение данной загадки. Тем самым мы получаем не один, а два теста, которые выполняются в несколько раз быстрее и дают исчерпывающие знания в случае ошибки. Не тратим время на анализ и разбор логов.
Как внедрить модульное тестирование?
Согласитесь, что простой целой команды на протяжении сколько-нибудь длительного времени это уже катастрофа? Поэтому основная польза от внедрения промежуточного этапа модульного тестирования в команду достаточно очевидна. Осталось только донести её до всех участников процесса и заинтересованных в конечном результате лиц.
Для начала нужно принять как данность, что не все понимают что вообще за зверь — модульное тестирование. Необходимо провести некоторую разъяснительною работу среди команды и доступно изложить всё то, что рассматривалось выше по поводу отличий такой команды от классических тестировщиков.
После подготовительной работы основная задача — добиться внедрения подхода с модульным тестированием хотя бы в тестовом режиме, выделив на это небольшую часть ресурсов.
После проведения нескольких показательных спринтов с новой формацией команды доказательствами эффективности такого подхода будут служить:
Заключение:
В итоге, по завершении всех вышеперечисленных операций по внедрению, модульное тестирование должно стать неотъемлемой частью процесса, которая позволит: