JavaScriptのユニットテストの書き方を読んだ

読んだ。

なるほどと思うことだらけだったので引用しまくる。

前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。

導入されていないプロジェクトに仕事では出くわしたことはないが、個人開発ではほぼ書かないので、まず書きます。

ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。

たしかに、テストコードはとっつきにくさを感じることが多い。書きやすさを重視するのは大事だな。

自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事。

耳が痛い話だ……。自分も既存テストのコードはよくコピペするので、その礎をまず自分が作らねば。

最初は言語やフレームワークの便利機能等をあえて忘れて、あえて頭を悪くして愚直に書く。頭がいいアサーションも、頭がいい context も避ける。

テストは動作保証でありつつ、ついでにアプリケーション内で「もっとも信用できるコピペ元」にならなければならない、と自分は思っている。実装をラップした賢いアサーションも、特にカバレッジを上げるような場合は必要だが、それとAPIの使い方を表明するようなテストは別に書く。

とにかく最初のハードルを下げようという話。本当にそのとおりだと思います。

このとき、__tests__ や test/**ではなく、実装したいディレクトリで実装してしまってよい。

異論はあると思うが、テストが見えないディレクトリに隠蔽されていることで、見た目上きれいになっても、維持する対象という意識が薄れて、テスト意識が低い人に放置される害のが大きいと感じている。テストは消極的な存在ではなく、積極的に混ぜていったほうが逆にいいと考えている。

なるほどなあ。テストコードはtestsディレクトリに分離するものだという固定観念があったが、こっちのほうがテストの可視化はされるし普段から意識できるしなあ。

フロントエンド特有の事情もあったり、異論はあると思うが、少なくとも自分はユニットテストは自分自身のために書いていて、それが結果として全体最適になると思っている。

もうほんと、そのとおりしか言葉が出ない。こういう意識を正しく持てるように啓蒙してくれる素晴らしい記事だった。