Вернуться к первой части

Концепция очаговой модели внедрения тестов

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

Рассмотрим пример. Допустим у вас есть три подсистемы:

• Система А: полностью покрыта тестами, своеобразный эталон;
• Система Б: система с большой долей легаси кода, частично покрыта тестами;
• Система В: очень древний код, но при этом активно задействованный. Тесты отсутствуют.

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

Многие начнут решать эту задачу с перемещения кода систем Б и В в А; улучшения его посредством рефакторинга до уровня А и после чего приступить к переписыванию тестов в системе Б и созданию новых на В того же уровня и с той же «базой», что существующие тесты для А.

Я считаю такую практику приращения ошибочной. Тактика единого центра приводит к своего рода эффекту «накопления усталости» - неизбежному переносу неправильных архитектурных решений из тестируемых подсистем (ведь тесты в каком-то смысле являются отражением тестируемого кода) в саму архитектуру тестовой системы и последующее умножению их друг на друга. Также такая стратегия приводит к затягиванию цикла разработки с большой вероятностью вообще никогда ее не закончить.

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

Основную суть предлагаемой мною модели хорошо отражает фотография с чашкой Петри представленная ниже.

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

Пожалуй, основным недостатком такого подхода является дублирования кода базовых классов тестовых подсистем. Но на самом деле дублирование - это не самый страшный «грех», в любом случае в дальнейшем для устранения образовавшегося дублирования можно объединить все тестовые подсистемы в одну.

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

Продолжая аналогию c чашкой Петри, в которой происходит распространение споровой культуры с общей ДНК, в очаговой модели нам нужна некая общая основа с хорошей и универсальной базой для независимого развертывания тестов, которой мы будем «заражать» наш код.

Основные требования к такой базе:

• независимое, самостоятельное, повторно используемое решение, способное существовать и развиваться изолированно; в нем должно быть заложено все, чтобы из него могла развиться полноценная тестовая система и в тоже время решение должно быть «прозрачным», минималистичным и ненагруженным лишним кодом.

• универсальное решение - пригодное для покрытия тестами любых систем,

• высокое юзабилити, удобство, понятность, простота освоения и интеграции с CI из коробки.

Итак «штаммом» для развертывания тестов должен стать минимальный набор кода, который можно было за пару минут развернуть в любой директории и в дальнейшем так же легко добавить в автоматический запуск на CI. Такой набор состоит из тестового фреймворка xUnit и некой своей базовой надстройки.

Очаговая модель и существующие тесты:

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

Продолжение следует…