Я разработчик Spring / Java (прежде всего) и сторонник модульного тестирования. Мои сотрудники создали несколько отличных постов в блоге по модульному тестированию ( особенно для Java ) для тех, кто также интересуется этой темой.
Часто ведутся споры о том, что представляет собой модульный тест, интеграционный тест, системный тест и т. Д. Но большинство из нас согласны с тем, что тесты не дают вам сойти с пути, когда проект становится достаточно сложным.
Тем не менее, я нашел очень мало дискуссий об архитектурных тестах. Что удерживает нас от непреднамеренного отклонения от нашей оригинальной, запланированной архитектуры? И, в конце концов, сколько корпоративных проектов даже поддерживают тех же самых архитекторов от начала инициативы до откладывания и замены?
В этом блоге я представляю ArchUnit, библиотеку тестов архитектуры Java для указания и утверждения правил архитектуры в простой Java. Мы обсудим, как это работает для снижения архитектурных рисков при разработке качественных корпоративных приложений.
Архитектурная структура Дебаты и риски
Архитектурная структура часто является еще одним источником споров в среде команды разработчиков программного обеспечения.
- Как должен быть организован код?
- Что команда собирается сделать, чтобы сохранить это таким образом?
- Собирается ли архитектор тратить время на проверку того, что ни один из членов команды не нарушает основные планы архитектуры всех проектов, за которые он отвечает?
- Кто позаботится о том, чтобы
System.outзвонки были удалены, прежде чем мы пойдем в производство? - После того, как мы выпустили prod, но на прошлой неделе нам пришлось отследить эту большую ошибку, куда мы ее добавили
sysouts? - Откуда мы знаем, что наша цикломатическая сложность стала слишком большой, и пришло время провести рефакторинг?
- Кто гарантирует, что на этапе обслуживания кто-то не будет добавлять вызовы из наших объектов модели в наши контроллеры или представления?
В конечном итоге это ответственность архитектора или руководителя команды. Но по мере приближения сроков мы склонны «просто заставить эту последнюю вещь работать». Надеемся, что позже будет время исправить «некрасивые биты», но приоритеты часто не устанавливаются архитекторами или командами, пишущими код.
Вы можете вообразить, что после того, как основные разработчики и архитекторы продолжат работу, нарушаются еще больше правил, и отсутствует непосредственное управление фазами исправления ошибок и обслуживания.
Представляем ArchUnit
ArchUnit — это отличная библиотека, которая много делает для вас, чтобы снизить эти риски.
Это среда модульного тестирования Java, поэтому вам не нужно изучать новый инструмент. У него есть предопределенные классы, которые проверяют общие ошибки, но они расширяемы, так что вы можете написать свои собственные правила и пользовательские бизнес-проверки, которые могут относиться только к вашей компании или даже к конкретному проекту.
Он использует Java Reflection API для проверки текущего состояния кода в любом случае. Команда ArchUnit предоставила отличные примеры в своем коде на GitHub . Я призываю вас проверить это!
В качестве примера, вот типичный пример, предоставленный ArchUnit для ловли скрытых нарушителей слоя …
ArchUnit/archunit-example/src/main/java/com/tngtech/archunit/example/persistence/layerviolation/DaoCallingService.java
public class DaoCallingService implements ServiceInterface {
public static final String violateLayerRules = "violateLayerRules";
public static final String violateLayerRulesTrickily = "violateLayerRulesTrickily";
ServiceViolatingLayerRules service;
void violateLayerRules() {
service.doSomething();
}
void violateLayerRulesTrickily() {
new SomeMediator(service).violateLayerRulesIndirectly();
}
}Увидеть его в действии
Вот проект, в котором я демонстрирую, как я вижу работу библиотеки ArchUnit в моих проектах.
преимущества
Самым большим преимуществом, которое я вижу, является возможность создавать эту группу архитектурных правил и использовать ее снова. Даже если новый член присоединится к команде, они быстро изучат правила, если у них будут повторяющиеся модульные тесты, которые определяют параметры.
Когда вы обнаружите крайний случай или что-то, что не было охвачено тестированием, вы можете написать тесты, чтобы покрыть его. Тесты выполняются в том виде, в котором вы их настроили, чтобы вы могли убедиться, что каждая регистрация проверена, ночные сборки проверены или только когда вы переходите в производство.
Последние мысли
Со временем это может стать внутренней общей библиотекой архитектурных правил, которую вы устанавливаете в начале проекта, чтобы с самого начала держать всех на одной странице.
В конце концов, чем меньше времени уходит на проверку того, что может быть автоматизировано, тем больше времени уходит на то, что невозможно. Я рекомендую вам попробовать ArchUnit.