Характеристики архитектуры Java модульного тестирования с помощью этой платформы

Простые в использовании функциональные тесты архитектуры и пригодности

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

Благодаря разработке, управляемой тестированием, инструментам статического анализа кода (таким как PMD и Checkstyle) и конвейерам непрерывной интеграции (CI) вы, по крайней мере, уверены, что любые критические изменения в коде, качестве кода и форматировании кода будут поддерживается.

Кроме того, благодаря инструментам покрытия кода, таким как Cobertura, вы знаете, какой процент кода действительно прошел модульное тестирование.

Обзор общего кода

Даже со всеми этими инструментами, когда я делаю обзоры кода, я ищу такие вещи:

• Никакие классы не должны генерировать общие исключения.
• Не писать в System.out (а использовать вместо этого ведение журнала).
• Ни один класс не должен использовать ведение журнала утилит Java (Прочтите, почему).
• Обслуживание работает, поэтому классы DAO должны находиться в пакетах DAO, а Entities должны находиться в пакетах Domain или Model .
• Интерфейсы не следует помещать в пакеты реализации.
• Классы интерфейса не должны начинаться или заканчиваться словом interface.
• Многоуровневые зависимости. Например, Services не должен обращаться к классам Controller , а классы DAO/persistence не должны обращаться к службам.
• Правильное использование пакетов безопасности Java.
• Осознанное использование сторонних библиотек.

И тому подобное.

У меня не всегда есть возможность сесть с контрольным списком и проверить передовой опыт. Человеческие ошибки естественны. Следовательно, я искал что-то, что могло бы выполнять эти проверки как часть наших сборок CI.

Мои поиски чего-то подобного остановились на библиотеке под названием ArchUnit.

Что такое ArchUnit?

Как указано на сайте ArchUnit:

«ArchUnit - это бесплатная, простая и расширяемая библиотека для проверки архитектуры вашего кода Java с использованием любой простой среды модульного тестирования Java.

То есть ArchUnit может проверять зависимости между пакетами и классами, слоями и срезами, проверять циклические зависимости и многое другое. Это делается путем анализа заданного байт-кода Java и импорта всех классов в структуру кода Java.

Как использовать ArchUnit

Вы можете добавить зависимости в тестовую область с помощью Maven следующим образом:

Или, если вы используете Gradle:

dependencies {
    testCompile 'com.tngtech.archunit:archunit:0.8.0'
}

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

Существуют встроенные общие правила, которые можно использовать как есть. Правила доступны в этом пакете:

com.tngtech.archunit.library.GeneralCodingRules

Подробности можно найти здесь.

Написание собственных правил

Да, вы можете написать свои собственные правила.

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

Прочтите эту информацию о том, как вы можете составлять свои собственные правила.

Примеры

Вы можете ознакомиться со следующим репозиторием GitHub для получения подробных примеров:

Похоже на: JUnit

Это очень похоже на то, что мы делаем в JUnit. Вы можете использовать аннотации, которые могут включать или отключать тест.

Тестирование ArchUnit

Тестирование похоже на то, как вы запускаете свои модульные тесты в Maven:

mvn test

Или, если вы используете Gradle:

gradle test

Заключение

Я считаю, что это хорошее начало для внедрения бережливой архитектуры.

Недавно я писал о Легких записях решений по архитектуре (LADR). Он идет рука об руку с ArchUnit.

Если вы попробуете это сделать, поделитесь своим опытом.