TypescriptでArchUnitしてみた
ArchUnit をというものを最近知りました。依存関係のテストができるそうです。さっそく試してみたいと思いますので、その備忘録として残しておきます。
ArchUnit
ArchUnit is a free, simple and extensible library for checking the architecture of your Java code using any plain Java unit test framework. That is, ArchUnit can check dependencies between packages and classes, layers and slices, check for cyclic dependencies and more. It does so by analyzing given Java bytecode, importing all classes into a Java code structure.
Java のアーキテクチャをテストできるライブラリで、パッケージやクラス、レイヤー、スライス（？）の依存関係をテストできるそうです。 そこで、親の顔よりも見たこの図をテストしたいと思います。
Typescript でも ArchUnit したい
ArchUnit は Java 製です。私は Typescript の ArchUnit がしたいです。 そこで、良さげなライブラリを発見しました。
特に拘りなく、アーキテクチャのテストができれば何でも良いかなと思います。 極端な話、ソースコードを AST パースし、依存関係を抽出できれば自作できるんじゃないかと思います。
試してみた
試したソースコードは、下記に置いています。ご参考下さい。
全体のソースコードツリーは次の構成です。
src
└ 1_enterprise_business_rules
└ entities
└ Entity.ts
└ 2_application_business_rules
└ use_cases
└ UseCase.ts
└ 3_interface_adapters
└ controllers
└ Controller.ts
└ gateways
└ Gateway.ts
└ presenters
└ Presenter.ts
└ 4_frameworks_and_drivers
└ web
└ Web.ts
└ clean_architecture.puml
└ clean_architecture.test.ts各プロダクトコードは、下の階層のファイルを import しているだけとします。
// src/4_frameworks_and_drivers/web/Web.ts
import "../../3_interface_adapters/gateways/Gateway";
import "../../3_interface_adapters/controllers/Controller";
import "../../3_interface_adapters/presenters/Presenter";// src/3_interface_adapters/controllers/Controller.ts
import "../../2_application_business_rules/use_cases/UseCase";// src/2_application_business_rules/use_cases/UseCase.ts
import "../../1_enterprise_business_rules/entities/Entity";// src/1_enterprise_business_rules/entities/Entity.ts下記ファイルにある UML のコンポーネント図で依存関係を表します。
## clean_architecture.puml
@startuml
component [4_frameworks_and_drivers] #Blue
component [3_interface_adapters] #Green
component [2_application_business_rules] #Red
component [1_enterprise_business_rules] #Yellow
4_frameworks_and_drivers --> 3_interface_adapters
3_interface_adapters --> 2_application_business_rules
2_application_business_rules --> 1_enterprise_business_rules
@endumlUML を可視化すると、下記の図のとおりです。
テストコードは、下記のとおりです。
// clean_architecture.test.ts
describe("architecture", () => {
it("Check dependency", async () => {
const architectureUml = path.resolve(__dirname, "clean_architecture.puml");
const violations = await slicesOfProject()
.definedBy("src/(**)/")
.should()
.adhereToDiagramInFile(architectureUml)
.check();
await expect(violations).toEqual([]);
});
});このテストケースは PASS します。
では、違反コードを書いてみます。
// src/3_interface_adapters/controllers/Controller.ts
import "../../2_application_business_rules/use_cases/UseCase";
import "../../4_frameworks_and_drivers/web/Web";3 レイヤーが上位の 4 レイヤーを使用しています。この状態でテストを実行すると、
見事 Failed となりました。つまり、依存関係の誤りを自動的に検出することができます。
最後に
規模が大きなプロジェクトほど、依存関係が複雑になりがちです。(Java でいう) パッケージやクラスの依存関係を適切に設計できていたとしても、誰かが壊しかねません。せっかく設計したのに壊されるのは、とても残念なので、テストコードで守ってあげましょう！
-
シェアする
フォローする
関連する記事
タグ「フロントエンド」の記事
最近、ヒューマンインターフェース ガイドライン（HIG）という言葉を知りました。 「ヒューマンインターフェイスガイドライン」には、どのAppleプラットフォームでも優れた体験を設計できるようにするためのガイドとベストプラクティスが含まれてい
2026-01-24
主にWeb関連の個人開発をしている際に心がけていることを書きます。 月末に近づくにつれ、AIの利用上限に達してしまうことがあります。 その状況になった時、以下のいずれかの選択肢が私の中では残っています。 課金して利用上限を増やす 無料モデル
個人サイトをリニューアルをしています。 ノート風のデザインを目指して、スタイルを調整していました。 ノートの見た目は、現実にあるノートを再現しようとCSSを書いていました。 現在、以下の画像のようなノートになっています。 ノート風デザインの
2026-01-20
タグ「テスト」の記事
Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。 flex-shrink の指定を忘れて、要素が押しつぶされてしまった z-index の指定を間違えて、要素が意図せず前面（また
AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。 単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。 興味があれば、参考として読んでもらえると嬉しい
2026-01-09
はじめに Playwright で E2E テストを書く際、playwright codegen や、近年では Playwright MCP を利用して、テストコードの雛形を作成することが多いと思います。 ただし、生成したテストコードが正し
2025-12-26
タグ「バックエンド」の記事
はじめに tRPCは、型安全なAPIを簡単に構築できるフレームワークです。開発中、バックエンドの実装を待たずに、Storybook上でフロントエンドの開発を進めたい場合、Mock Service Worker (MSW) を使用してAPIのモックを行うことができます。この記事では、maloguertin/msw-trpc を用いて、tRPC通信をMSWでモックする方法について解説します。実用例として、サンプルコードをGitHubリポジトリ silverbirder/trpc-msw-storybook-nextjs で共有しています。
Stable Diffusion は、文章を渡すと画像を生成してくれる AI で OSS です。これを自前で動かそうとすると、GPU が必要になります。