Продолжим изучать пирамиду тестов и рассмотрим, каким должен быть тестовый набор на проекте. Тесты пирамиды сгруппированы по разным уровням детализации системы, когда мы рассматриваем систему целиком, на самом верхнем уровне, ручного и автоматизированного тестирования пользовательского интерфейса, который в классической пирамиде Майка Кона представлен небольшим набором тестовых сценариев.
Реальная ситуация на проекте может отличаться от первоначально задуманной, когда преобладает мануальное тестирование, с привлечением большого количества тестировщиков, и в итоге мы получаем перевернутую пирамиду в виде рожка мороженого, являющуюся анти паттерном тестирования. Эта пирамида показывает, как делать нельзя:
Наибольшее количество тестов должно проводиться на уровне программных модулей, тогда многие ошибки не будут проявляться на верхнем уровне тестирования системы целиком. Таким образом, пирамида тестов представляет эмпирическое правило для написания тестовых наборов:
- тесты должны быть написаны для всех уровней детализации системы;
- тесты должны быть сгруппированы по различным уровням детализации;
- количество тестов на каждом уровне определяется правилом пирамиды, чем выше уровень, тем меньше тестов.
Кроме проблемы реализации тестового подхода на нижнем и верхнем уровнях пирамиды, когда большое количество быстрых модульных тестов лучше, чем большое количество медленных ручных тестов всей системы, существует также проблема деления среднего уровня интеграционных тестов на множество сервисных слоев, для тестирования служб разных уровней.
Не могу сказать, что это плохо, делать тесты для всей бизнес-логики приложения. Подход к тестированию, при котором формируются горизонтальные слои уровней тестирования бизнес-структур приложения, рассматривает объектную модель домена в качестве слоя данных.
Аргументом для отказа от подхода к тестированию сервисных слоев является потеря больших возможностей структуризации данных на основе объектно-ориентированного подхода, и соответственно, более структурированному и легко читаемому тестовому набору.
При объектно-ориентированном подходе мы тестируем не только данные объекта, но и функции, определяющие правила отношений между этими данными, бизнес-правила. Поскольку на уровне интеграции первично поведение системы, при реализации методологии BDD, доменная модель, представляющая все данные приложения, работает с данными, полученными из баз данных, и с ответными сообщениями API. Этот подход повышает надежность тестов, делает его гибким и легко поддерживаемым. Эти три характеристики тестов являются ключевыми при выборе подхода к разработке и тестированию.
Существует также контраргумент к тестированию бизнес-логики по объектной модели. Дело в том, что приложения, написанные на языке С, либо переписанные с более ранних языков, реализуют процедурный подход, и бизнес-логика распределена по всей системе, а не выделена в отдельный слой функций, что значительно упростило бы ее тестирование.
Если понравилось, ставьте лайк. Если есть вопросы, пишите комментарии. Поскольку тема эта неисчерпаема, вернемся к ней еще не раз.