(自分の) JavaScript のユニットテストの書き方

(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事

[zuboriradio]

“ここで意識することとして、expect() のアサーションも .toBe() や .equal() のような単純なものしか使わないようにしている。複雑なアサーションを使うと、実装者は気持ちいいかもしれないが、第三者には読めない。”

[yarumato]

“ユニットテスト導入コストを、限界まで低くする。こうしないとメンテコストが高く実行時間が長いE2Eを大量に書くことになるから。JSは常にフレームワークが変動してるので複雑な知識は覚えても持ち越せない。”

[mk_55]

メモ

[mizdra]

良い。テストファイルをテスト対象のファイルと同じ場所に置くのは僕もやってる。テストの存在が身近になるので心理的に書きやすくすること、お手本となるテストを探しやすくすることが狙い。

[mumei-0]

“今回は vitest を使う。mocha, ava, jest と今まで使った中で一番体験がいい。 API が jest 互換なので、移行しやすい。”

[opera627]

“ユニットテストは自分自身のために書いていて、それが結果として全体最適になる”同意

[fuyu77]

"テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し……こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく"

[tkmkg8m]

細かい方針は自分と考え方が違うけど、おおまかには同意。あとVitest知らなかったけどよさげね。

[h_taiji]

vitest使ってみる

[igatea]

参考になる。最後の本番コードにテストコードを書くのはVitestがソース内テストをサポートしているからそれが使えるかも https://vitest.dev/guide/in-source.html

[kagehiens]

参考になる……気がする。

[uva]

「複雑なアサーションを使うと、実装者は気持ちいいかもしれないが、第三者には読めない」

[Nyoho]

“今回は vitest を使う。mocha, ava, jest と今まで使った中で一番体験がいい。 API が jest 互換なので、移行しやすい。”

[kazokmr]

最近フロントエンドの開発するようになったけどほぼ同意。例がロジックだけどUIならアクセシビリティも意識して書くようにしてる

[remonoil]

最初は簡易なアサーションに留めるのは同意だけど、それを模倣させると気付いた時にはそびえ立つ巨大な糞になってるのが悩ましい。やはり最適化は必須なんだよ

[lli]

ありがとうございます。助かる〜

[shior718]

ありがてえ。

[rochefort]

良い

[aktkro]

一つ目書かないと永遠に書く気がおこらないのわかる

[carolina04]

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

[turanukimaru]

複雑なコードのテスト（Mockが必要とか）はテスト自体も複雑になるし、対象のコードが単純なうちに単純なテストを書いてコードとテストの両方を単純に保つことを意識するのが良いかと思う。

[mizchi]

書いた