En utilisant une bibliothèque appelée ** ArchUnit **, il est possible de vérifier par test unitaire si le code source Java enfreint l'architecture.
Je vais vous présenter ce que vous pouvez faire avec ArchUnit, quel type de code ce sera réellement, etc.
ArchUnit est une Bibliothèque Open Source qui vous aide à effectuer des tests unitaires sur l'architecture Java. C'est une bibliothèque remarquable qui a également été publiée dans TECHNOLOGY RADAR.
Avec ArchUnit, vous pouvez vérifier les éléments suivants avec un test unitaire. (*)
n'est accessible qu'à partir de la classe avec
@ Transactional`.contrôleur → service → persistance
n'est pas autorisé.Les violations d'architecture sont moins susceptibles de se produire.
Traditionnellement, pour garder l'architecture propre
Je pense que j'ai souvent pris des mesures analogiques telles que. Par conséquent, si une erreur humaine se produit, le code qui viole l'architecture sera placé dans la branche principale.
Lors de l'utilisation d'ArchUnit, les tests unitaires peuvent détecter les violations d'architecture, afin que CI puisse vérifier les violations d'architecture. Ainsi, ** si les tests sont écrits correctement **, le code fusionné ne peut pas provoquer de violation d'architecture.
La méthode d'installation est décrite dans ici. Le code ci-dessous peut être trouvé à ici. (Testé avec JUnit 5)
Lors de l'écriture d'un test à l'aide d'ArchUnit, affectez d'abord @ AnalyzeClasses
à la classe de test.
Les classes incluses dans le package spécifié par packages
seront testées.
@AnalyzeClasses(packages = "nannany.arch.check.archunit")
public class ArchitectureTest {
Ce qui suit vérifie l'architecture qu'un package avec service
dans le nom du package ne peut pas dépendre d'un package avec controller
dans le nom du package.
/**
*Le pack de services est indépendant du contrôleur
*/
@ArchTest
public static final ArchRule servicesCantDependOnController = noClasses()
.that().resideInAnyPackage("..service..")
.should().dependOnClassesThat().resideInAPackage("..controller..");
La méthode de description est une image de l'écriture de la classe à tester sur le côté gauche de «should ()» et la règle sur le côté droit de «should ()».
Dans l'exemple ci-dessus, pour noClasses (). That () .resideInAnyPackage (" .. service .. ")
, la classe contenue dans le package nommé service
doit être à droite de should ()
. Cela signifie qu'aucune classe ne répond à la règle **.
Pour dependOnClassesThat (). ResideInAPackage (" .. controller .. ");
, il exprime la règle selon laquelle cela dépend du paquet nommé controller
.
ArchUnit prend en charge les architectures typiques. Actuellement, [Architecture multicouche](https://ja.wikipedia.org/wiki/%E5%A4%9A%E5%B1%A4%E3%82%A2%E3%83%BC%E3%82%AD % E3% 83% 86% E3% 82% AF% E3% 83% 81% E3% 83% A3) et Onion Architecture (Hexagonal Architecture)) Il semble y avoir un soutien pour.
Dans ce qui suit, nous utilisons des méthodes qui prennent en charge l'architecture multi-niveaux pour vérifier l'accès entre les couches autres que Controller → Service → Persistence
.
/**
*Utilisation de l'architecture en couches
*/
@ArchTest
public static final ArchRule layeredArchitecture = layeredArchitecture()
.layer("Controllers").definedBy("nannany.arch.check.archunit.controller")
.layer("Services").definedBy("nannany.arch.check.archunit.service")
.layer("Repositories").definedBy("nannany.arch.check.archunit.repository")
.whereLayer("Controllers").mayNotBeAccessedByAnyLayer()
.whereLayer("Services").mayOnlyBeAccessedByLayers("Controllers")
.whereLayer("Repositories").mayOnlyBeAccessedByLayers("Services");
https://www.archunit.org/ https://www.thoughtworks.com/radar/tools/archunit
Recommended Posts