はじめに

Goのinternalパッケージはご存知でしょうか？
本記事では、うまく使うととても便利なinternalパッケージについてご紹介します。

internalパッケージとは

Goパッケージは、基本的には外部のモジュールに公開されます。
パッケージ内のどの識別子を公開するかは、先頭の文字を大文字にするかどうかで決まりますが、パッケージにはその機能はありません。

しかし、Goにはinternalパッケージ（内部パッケージ）という特別なパッケージがあります。internalパッケージは、モジュール外には公開されません。
また、internalパッケージの親パッケージおよびその子パッケージ以下からしか参照できません。

たとえば、以下のようなパッケージ構成があった場合を考えます。

a
├── b
│   ├── d
│   └── internal
│       └── e
├── c
└── go.mod

a/b/internalパッケージ直下の識別子やa/b/internal/eパッケージの識別子は、一部のパッケージからしか参照できません。
パッケージbとパッケージd以下およびinternalパッケージ以下のパッケージからの参照に限定されます。
パッケージaやパッケージcからは参照できません。

もちろん、internalパッケージ以下のパッケージで識別子を非公開（小文字で始める）にした場合は、そのパッケージ内だけからしか参照できません。
なお、internalパッケージはモジュール以下にいくつでも作れます。

テストをしやすくする

筆者は、テストコードはテスト対象のパッケージとは別のパッケージにした方が良いと考えています。
つまり、aパッケージをテストしたい場合は、テストコードはa_testパッケージにする方が良いということです。

テストコードを別パッケージにすることで次のような利点が得られます。

単体テストがパッケージの初めてユーザになる
使い勝手や使用した場合可読性を図りやすい
早めに設計ミスなどに気づける

また、一方で次のような煩わしさが残ります。

非公開な機能を使ったテストがしづらい
わざわざ、別のパッケージにするのがめんどくさい

非公開な機能のテストは、export_test.goを使ったパターンでほとんどの場合は解決します。
テストで使用する非公開な機能をAllowリスト形式で並べることにもなるため、テストのときだけの特別扱いを避けやすくなります。

しかし、非公開な機能で複雑な処理をしている場合、どうしてもテストがしたくなります。
その場合に有効なのがinternalパッケージです。

複雑な処理をしている非公開な機能をモジュール内ライブラリのような形で切り出し、internalパッケージ以下に配置することで特定のパッケージからしか参照できないように制限できます。
そして、internalパッケージ以下では公開された機能としてテストすればexport_test.goを使う必要もありません。

モジュールやパッケージ間を疎結合にする

実はGoチームが管理しているモジュールの多くでinternalパッケージが利用されています。
公開する必要がない場合はinternalパッケージ以下に置くようなレベルで管理されているモジュールもあります。

たとえば、Webアプリのようなものであれば、エントリーポイントとなるmainパッケージを含むパッケージのみ公開し、他のパッケージはモジュール直下にあるinternalパッケージ以下に配置するという方法がとられます。
pkg.go.devのソースコードを見てもモジュール直下にinternalパッケージがあることが分かります。

他のモジュールやパッケージから参照されてほしくないパッケージはinternalパッケージに置いておくと、後方互換を気にせずに破壊的変更が行える利点があります。
ライブラリでもWebアプリでもこの利点は効いてくるでしょう。

おわりに

本記事ではinternalパッケージの活用について紹介しました。