Zenn
Open8

結局テストファイルはどこに置くのがベターなのか

takumi-ntakumi-n

Jest でのテストがメイン
以下のような流派があるっぽい

各パターンのメリット/デメリットを検討してみる

パターン1. プロジェクトルートに __tests__ や tests を作り、ソースコードのディレクトリ構造と同じ構造を複製する。テスト対象のモジュールと対応する場所にテストコードを配置する

.
├── __tests__
│   ├── a.test.js
│   └── dir1
│       └── b.test.js
└── src
    ├── a.js
    └── dir1
        └── b.js

パターン2. ソースコードの各ディレクトリに __tests__ や tests ディレクトリを作り、同階層のモジュールのテストをそのディレクトリの中に配置する

.
└── src
    ├── __tests__
    │   └── a.test.js
    ├── a.js
    └── dir1
        ├── __tests__
        │   └── b.test.js
        └── b.js

パターン3. モジュールに隣接する形でテストを書く

.
└── src
    ├── a.js
    ├── a.test.js
    └── dir1
        ├── b.js
        └── b.test.js
takumi-ntakumi-n

パターン1

メリット

  • テストコードとアプリケーションコードを完全に分離できる→ソースコード領域をクリーンに保てる
  • ビルドやデプロイフローでソースコードディレクトリ内をすべてバンドル対象・デプロイ対象とするような設計の場合、実行時には不要なファイルを含まなくて済む
  • [他メリット要調査]

デメリット

  • テストコードのソースコードの行き来が大変である→保守しにくい。ただこの点は IDE やエディタの支援が受けられるのであればさほど問題ないのかもしれない
  • テスト対象が明確でない
  • テスト対象の import がめんどくさい。相対パス ../../.. ....
  • GitHub PR レビューのときに離れて表示されるためレビューしにくい

参考

takumi-ntakumi-n

パターン2

メリット

  • テストファイルとソースコードの行き来が楽
  • テスト対象が明確である
  • テスト対象の import が楽
  • ソースコードとテストコードが適度に分離される。パターン1とパターン3の折衷案的ポジション
  • [他メリット要調査]

デメリット

  • GitHub PR でファイルがやや離れる可能性がある
  • [他デメリット要調査]

参考

takumi-ntakumi-n

パターン3

メリット

  • テストファイルとソースコードの行き来が楽
  • テスト対象が明確である
  • テスト対象の import が楽
  • GitHub PR でファイルが並ぶのでレビューが楽
  • [他メリット要調査]

デメリット

  • ソースコードディレクトリがテストコードでいっぱいになる
  • [他デメリット要調査]

参考