Archunit: Проверка архитектуры наших проектов

Когда вы создаете микросервис или библиотеку, вы начинаете определять расположение каждой группы элементов (перечислений, классов, интерфейсов) в одном или нескольких пакетах и рекомендуемые методы, т.Е. если вы используете Spring Boot, контроллеры должны быть помечены @RestController . Поначалу все будет хорошо, потому что над проектом работает небольшая группа разработчиков. Однако, когда вы начинаете добавлять разработчиков из своей команды или из другой команды в компании, добавьте новые функциональные возможности, когда появляется ошибка.

Чтобы предотвратить любую ошибку в коде проекта, кто-то из вашей команды должен просмотреть все изменения перед объединением в master. Этот подход выглядит хорошо в начале, но есть некоторые проблемы:

• Действительно трудоемкие задачи
• Правила могут измениться в будущем, поэтому каждый должен знать новые правила, прежде чем проверять какой-либо код.

В глубине души первым решением были бы такие инструменты, как Checkstyle , PMD или Findbugs |/, которые выполняют статический анализ кода, но эти инструменты не имеют возможности проверять структуру проекта.

Несколько лет назад Появился Arch unit , который представляет собой бесплатную и расширяемую библиотеку для проверки архитектуры вашего проекта с помощью простого модульного теста. Эта библиотека дает вам возможность проверить структуру слоя (какой пакет/класс зависит от другого), допустимые аннотации в каждом классе, проверить наличие циклических зависимостей и многое другое.

Чтобы запустить модульные тесты Arch, вам нужно будет добавить зависимость, связанную с используемой вами версией Junit .

    com.tngtech.archunit
    archunit-junitX //"X" could be 4/5
    0.15.0
    test

После добавления зависимости ваш первый модульный тест Arch должен выглядеть так, как показано в примере ниже:

Позвольте мне подробно объяснить каждый блок кода:

1. С помощью этой аннотации вы указываете Arch unit, какой пакет должен проверять все правила, хорошей практикой является размещение пакета, содержащего все объекты вашего проекта. Кроме того, практика говорит Arch unit не проверять тест только на код, который что-то делает.
2. Вам необходимо указать, что поле или метод являются модульным тестом Arch.
3. Это тест со всеми условиями для проверки. В примере проверяется, что все поля внутри любого класса в этом конкретном пакете не являются общедоступными. Просто чтобы уточнить, “fields()” – это статический импорт ” com.tngtech.arch unit.lang.syntax.ArchRuleDefinition.поля”

В этом посте вы можете увидеть несколько примеров того, какие вещи вы можете проверить с помощью Arch unit .

Общие правила кодирования

Модуль Arch определяет некоторые общие правила кодирования, которые вы можете использовать для проверки вашего проекта, большинство из них определены в классе “GeneralCodingRules”. Чтобы использовать эти правила, вам необходимо добавить тест в свой проект, вот некоторые примеры этих правил:

Соглашения об именовании

Вы можете проверить, что все объекты в одном конкретном пакете содержат суффикс, например xxxController или xxxService.

Многоуровневая архитектура

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

Возвращаемый тип

В конечных точках контроллера вы можете проверить тип ответа. Например, в случае Spring Boot хорошей практикой является возврат “ReponseEntity”.

Аннотации

Иногда вам нужно проверить, что некоторые классы/интерфейсы/методы или поля используют определенную аннотацию.

В некоторых случаях методы проверки некоторых правил по умолчанию не покрываются Arch unit, поэтому вы можете создавать пользовательские условия, такие как проверка того, что ваши объекты entities/model содержат методы “equals” и “hashcode”.

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

• Определите пакет анализируемых классов, имя пакетов или любую константу в одном классе, чтобы иметь место со всеми константами, которые вы используете во всех тестах.
• Определите правила таким образом, чтобы вы могли повторно использовать их в разных местах, т.Е. вы можете создать правило, которое проверяет, что частные методы запрещены, и вызывать эти методы из разных мест.
• Попробуйте поместить все правила, относящиеся к одной группе проверки, в один класс, т.е. создайте класс, который содержит все правила, относящиеся к проверкам контроллера в случае одного микросервиса.
• Разделите каждый тестовый класс, чтобы более простым способом найти все проверки, связанные с классами, полями, конструкторами и методами. На данном этапе важно иметь возможность легче идентифицировать каждую группу и иметь возможность предотвратить проверку одних и тех же тестов другим способом.

Arch unit – это мощная библиотека, которая дает вам возможность проверять каждое правило, которое вы можете себе представить в своей архитектуре, и сокращать количество ошибок в ваших проектах.

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

Для любопытных, вот код на Github:

• Мои примеры
• Другие примеры

Оригинал: “https://dev.to/andressacco/archunit-validate-the-architecture-of-our-projects-3hc9”