ホーム自己紹介ブログ
NO.57
DATE2020. 11. 28

TypescriptでArchUnitしてみた

ArchUnit をというものを最近知りました。依存関係のテストができるそうです。さっそく試してみたいと思いますので、その備忘録として残しておきます。

ArchUnit

Unit test your Java architecture

Start enforcing your architecture within 30 minutes using the test setup you already have.

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 のアーキテクチャをテストできるライブラリで、パッケージやクラス、レイヤー、スライス(?)の依存関係をテストできるそうです。 そこで、親の顔よりも見たこの図をテストしたいと思います。

Clean Coder Blog > The Clean Architecture

Typescript でも ArchUnit したい

ArchUnit は Java 製です。私は Typescript の ArchUnit がしたいです。 そこで、良さげなライブラリを発見しました。

GitHub - ts-arch/ts-arch: An architecture unit test framework for Typescript

An architecture unit test framework for Typescript - ts-arch/ts-arch

GitHub

特に拘りなく、アーキテクチャのテストができれば何でも良いかなと思います。 極端な話、ソースコードを AST パースし、依存関係を抽出できれば自作できるんじゃないかと思います。

試してみた

試したソースコードは、下記に置いています。ご参考下さい。

GitHub - silverbirder/try-archunit

Contribute to silverbirder/try-archunit development by creating an account on GitHub.

GitHub

全体のソースコードツリーは次の構成です。

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
@enduml

UML を可視化すると、下記の図のとおりです。

clean_architecture.puml

テストコードは、下記のとおりです。

// 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/clean_architecture.test.ts > architecture > Check dependency #Succeed

では、違反コードを書いてみます。

// src/3_interface_adapters/controllers/Controller.ts
import "../../2_application_business_rules/use_cases/UseCase";
import "../../4_frameworks_and_drivers/web/Web";

3 レイヤーが上位の 4 レイヤーを使用しています。この状態でテストを実行すると、

src/clean_architecture.test.ts > architecture > Check dependency #Failed

見事 Failed となりました。つまり、依存関係の誤りを自動的に検出することができます。

最後に

規模が大きなプロジェクトほど、依存関係が複雑になりがちです。(Java でいう) パッケージやクラスの依存関係を適切に設計できていたとしても、誰かが壊しかねません。せっかく設計したのに壊されるのは、とても残念なので、テストコードで守ってあげましょう!

フロントエンド
テスト
バックエンド

-

読者になる

|

シェアする

|

silverbirders

silverbirder

Webソフトウェアエンジニア

ブログを応援する

この記事がよかったら、お布施という形で応援してもらえるとうれしいです。

おふせぼたん

※ ログイン不要で投稿できます。

※ 同じブラウザから投稿を削除できます。

0

読み込み中...

次の記事へ前の記事へ

関連する記事

タグ「フロントエンド」の記事

Webフロントエンドのコードレビューメモ2

また、以下の記事の続きを書こうと思います。 https://silverbirder.github.io/blog/contents/20260312/ ビジネスロジック アプリケーションのビジネスロジックに関することについて書きます。 複

2026年03月18日

フロントエンド
Webフロントエンドのコードレビューメモ

Webフロントエンドのコードレビューをしているときに考えていることについて書きます。 毎日1記事投稿、1記事30分という制約を課していますので、本記事は完璧ではありません。(言い訳) また希望的な考えもあるので、実践していないものもあります

2026年03月12日

フロントエンド
AIの書いたコードの手直しを減らすお作法

AI にコードを書かせた後、余計なコードを見つけて消す作業があります。 不毛なことなので、それらの作業を減らすためのお作法を紹介します。 未使用コードを消す 以下でも書きましたが、未使用コードの検査に knip を使うことが多いです。 ht

2026年02月25日

AI
フロントエンド

タグ「テスト」の記事

CSSを、Vitestでテストしてみる

以下の記事で書いた CSSをテストする方法について、試してみました。 https://zenn.dev/silverbirder/articles/df6752b230f04c ソースコードは、以下に置いています。 https://gith

2026年02月10日

フロントエンド
テスト
CSS Layout Testing というテスト手法の提案

Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。 flex-shrink の指定を忘れて、要素が押しつぶされてしまった z-index の指定を間違えて、要素が意図せず前面(また

2026年01月10日

フロントエンド
テスト
単体テストを全通り書くんじゃない!

AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。 単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。 興味があれば、参考として読んでもらえると嬉しい

2026年01月09日

テスト

タグ「バックエンド」の記事

Storybook上で tRPC通信をMSWでモックする方法

はじめに tRPCは、型安全なAPIを簡単に構築できるフレームワークです。開発中、バックエンドの実装を待たずに、Storybook上でフロントエンドの開発を進めたい場合、Mock Service Worker (MSW) を使用してAPIのモックを行うことができます。この記事では、maloguertin/msw-trpc を用いて、tRPC通信をMSWでモックする方法について解説します。実用例として、サンプルコードをGitHubリポジトリ silverbirder/trpc-msw-storybook-nextjs で共有しています。

2024年03月07日

テスト
バックエンド
GraphQL Guildのエコシステムって便利だね

GraphQL Guild ってご存知ですか?GraphQL 界隈だと、Code Generator が有名と思いますが

2022年10月15日

バックエンド
Stable Diffusion API 開発

Stable Diffusion は、文章を渡すと画像を生成してくれる AI で OSS です。これを自前で動かそうとすると、GPU が必要になります。

2022年09月03日

AI
バックエンド
成果物
← ブログ一覧へ