ときどきかなり複雑なロジックなものがあって 色々なケースを試すときに手作業よりはテストツールでやったほうが楽かなと思うくらいです
なので テストの目的は仕様を記載するか あれこれ変更したときに元の動作が維持できているかの確認という意図が強めです
一度作ったらその部分のコードにはできるだけ触れないという人もいますが 個人的には気になるところがあれば頻繁に修正加えていくタイプなのでリファクタリング時が一番の目的かもしれません
なのですが 大きく書き換えるとリファクタリング時に動作が変わっていないかのテストに使えないことが多いのですよね
小さい規模だと使えることが多いですが 期待するのは大きい規模での変更です
なのにそういうときにあまり使えないとなると 丁寧にテストしてもあまり意味ないかなぁという気持ちになりました
例えばモジュールまるごと置き換えるような場合
A モジュールがあってそれを使う B モジュールがあります
A はこういう感じです
export const logic1 = () => {}
export const logic2 = () => {}
export const logic3 = () => {}
// ...
export default () => {
// ここで logic1 や logic2 などを使う
}
B では基本 default export されたものを使います
場合によっては直接 logic1 などを使うかもしれませんが基本は default export のものです
複雑なロジックをテストするときって基本まとまった部分じゃなくて小さい単位で詳細にテストします
上の例だと logic1 ～ logic3 などです
default export する関数だと中でこれらを複数使ってるので この関数を使って logic1 の動きや logic2 の動きまで詳細にテストするのは大変です
例えば logic3 が重たい処理だった場合に logic1 部分のテストだけでも時間がかかってしまいますし
なので default export の関数自体のテストはシンプルで 中で呼び出す logic1 などに渡す引数が間違ってないかを確認する程度の目的です
この関数自体が十分にシンプルなら省略することもあります
リファクタリングで logic1 の中身だけ修正しようとなった場合は logic1 はちゃんとテストされているので 効果が高いです
しかし 大きな規模だと A モジュールをまるごと作り直すということもありえます
そうなると logic1 や logic2 という関数の分け方もなくなります
過去のテストは使い回せないです
B に影響させない範囲なら default export の関数のインターフェースはそのままですが この関数のテストは簡単なものしかありません
このテストが通っても最低限のパターンでしかなくて 複雑なケースが動くことは保証できません
これに対応しようとすると logic1 ～ logic3 の分のテストを default export の関数でもテストしておく必要が出てきます
それはテストケースがかなり増えて大変ですし 関数が何重にもなってくると現実的ではないです
B モジュールを使う C モジュールがあれば C モジュールでも A モジュールの中身までテストするということになります
C モジュールを使う D モジュール……と続いて Z モジュールまで行ったとき Z モジュールのテストで A モジュール内の logic1 の分岐全部をテストなんてやってられないですよね
そう考えるとリファクタリング時の安全を求めるという目的でのテストはあまり効率的ではなさそうです
