目录
0前言
1 背景
2 为什么选择 Archunit
3 Archunit 是什么
4 引入 Archunit
4.1 开始就是如此简单
4.2 如何组织架构规则
4.3 团队如何规范化
0前言
通过自动化单元测试的形式守护系统架构是一种有效的方式，可以确保系统在不断演进和修改的过程中保持稳定和可靠。
自动化单元测试是指通过编写测试代码来验证系统中的各个单元（如函数、类、模块等）是否按照预期工作。它可以帮助开发人员及时发现和修复代码中的问题，确保系统的各个组件在修改后仍然能够正常工作。
1 背景
随着需求开发迭代，代码库规模逐渐变大，新的团队成员引入等诸多因素，系统起初制定的架构规则不可避免遭到破坏。不仅仅是破坏团队的统一开发规范，更为重要的是随着代码库规模逐渐增长，大大降低系统的可维护性、扩展性，增加评审复杂度和重构成本，也最终导致团队生产力下降以及研发成本增长。
在敏捷开发环境下，系统通过迭代增量的交付价值，系统架构也是如此。团队不可能在项目之初就建立完美的系统架构，系统架构应该随着系统迭代不断演进。
架构演进和架构腐化是看待架构的不同视角：架构腐化着眼于现状，架构演进侧重于未来
架构腐化不可避免，随着时间流转腐化现象必然发生。而我们需要做的是：通过某种方式及早发现和修正
2 为什么选择 Archunit
我们需要通过引入一种机制或技术，降低或及早发现架构腐化现象的发生，保持统一的系统架构约束。
- 支持架构规则自动化检查
- 轻量级，接入成本低
- 结果及时反馈
- 灵活扩展且扩展成本低
对于架构规则常见的验证方式：代码评审、代码质量分析工具或平台、Archunit
以下对常见的几种方式进行优劣势对比：
代码评审：通过强流程控制代码评审活动发生，增强代码评审的强度和质量
优势
- 不需要引入额外的技术，没有学习成本
- 灵活：通过人工评审方式可以覆盖架构约束更全面
劣势
- 非自动化方式执行，质量靠人工保证，人为因素存在较多不可控因素
- 代码评审范围越广，人力成本投入则越大
- 代码评审流程后置，不能及时反馈规则检测结果
代码质量分析工具：比如 Sonar、Checkstyle 等
优势
- 成熟的工具或平台，内置开箱即用的规则
- 三方工具支持，不影响代码库结构
劣势
- 缺少灵活性，架构规则约束支持程度有限，不能很好的解决架构层面规则约束
- 强调代码质量分析结果，不能有效处理强制规则约束
- 定制规则有一定成本 (因平台扩展能力而异)
Archunit：通过单元测试形式对架构规则自动化检查
优势
- 支持丰富的架构约束规则定制能力，例如分层依赖规则、包依赖规则、循环依赖、继承关系约束等
- 虽然以单测代码方式体现，但不影响主业务开发，可以通过增量方式引入，逐步增强应用的架构约束能力
- Archunit 提供的 Java 流式 API 易于理解，接入和使用成本低
- 使用纯 Java 单测框架以单元测试形式自动化执行，及时反馈单测结果
劣势
- 需要额外编写单元测试代码，增加了一部分工作量
- 引入了新的类库有一定学习成本
3 Archunit 是什么
ArchUnit 是一款免费、简单可扩展的类库，它可以使用任何 Java 单元测试框架来检查 Java 代码的架构约束。基于 Archunit 我们可以自动化检测：
- 循环依赖
- 包的包含关系
- 类的依赖关系
- 类和包的包含关系
- 继承关系
- 注解
Archunit 和代码质量分析工具的关系如下图所示，二者都可以对代码进行分析，在功能覆盖上存在一定交叉。
Archunit*不能解决所有的架构属性的约束自动化验证*，其主要侧重于系统的演进性、可维护性、可测试性、可解释性等，也可以对耦合度、命名规范等进行验证。
4 引入 Archunit
4.1 开始就是如此简单
使用 Archunit 编写架构规则约束非常简单，其提供了便捷的流式 API，可以快速的构建规则。
示例 1：RULE.01 所有的枚举类必须以 Enum 为后缀
示例 2：对应用分层进行约束校验
在 IDE 下执行 Archiunit 单元测试结果示意如下图所示：
4.2 如何组织架构规则
架构规则组织可以从多个维度，比如：
下图左侧所示：基于逻辑分类对规则进行分组
下图右侧所示：基于职能分类对规则进行分组
4.3 团队如何规范化
团队是否要引入 Archunit 本身也是一项架构决策，建议采用文档化形式对该决策进行记录.
如果团队想要引入 Archunit，从流程化和规范化视角可以基于准备 - 试点 - 优化 - 推广的模式进行实施：
实施准备：
- 从规范复用的角度考虑，团队需要定义统一的开发规范，包括但不限于编码规范、异常规范、命名规范、依赖规范等等，并在团队内达成一致。建议采用统一的、文档化的形式进行记录 (比如，在线表格系统)。对于每条开发规则建议增加比如 “正例”、“反例”、“规则描述”、“规则详细说明”、“是否可自动实现” 等维度描述信息
- 基于 Archunit 实现通用架构约束以便在不同项目间进行复用
应用试点：在产品线内部选定一个试点应用
复盘优化：基于试点效果进行复盘，基于团队成员反馈进行架构规则优化、已有规则的修改及废弃等等
推广普及： 基于试点的一些实践在其它应用或业务线进行推广普及
对于遗留系统已经形成了特定的规则 (有可能是已经发生腐化)，由于业务系统的持续迭代，在单个迭代完全大规模重构已有系统的可能性不大。所以，建议采增量方式，在迭代研发资源可接受的范围内，逐步引入并丰富架构规则，并对破坏规则的应用代码进行重构。
作为一位过来人也是希望大家少走一些弯路
在这里我给大家分享一些自动化测试前进之路的必须品，希望能对你带来帮助。
（软件测试相关资料，自动化测试相关资料，技术问题答疑等等）
相信能使你更好的进步！
点击下方小卡片文章来源：https://www.toymoban.com/news/detail-600042.html
文章来源地址https://www.toymoban.com/news/detail-600042.html
到了这里，关于通过自动化单元测试的形式守护系统架构的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
