(自分の) JavaScript のユニットテストの書き方
2022/03/22 11:19
mizchi
書いた
2022/03/22 11:24
zuboriradio
“ここで意識することとして、expect() のアサーションも .toBe() や .equal() のような単純なものしか使わないようにしている。複雑なアサーションを使うと、実装者は気持ちいいかもしれないが、第三者には読めない。”
2022/03/22 13:00
masakinihirota
今回は vitest を使う。mocha, ava, jest と今まで使った中で一番体験がいい。
2022/03/22 13:05
yarumato
“ユニットテスト導入コストを、限界まで低くする。こうしないとメンテコストが高く実行時間が長いE2Eを大量に書くことになるから。JSは常にフレームワークが変動してるので複雑な知識は覚えても持ち越せない。”
2022/03/22 14:55
turanukimaru
複雑なコードのテスト（Mockが必要とか）はテスト自体も複雑になるし、対象のコードが単純なうちに単純なテストを書いてコードとテストの両方を単純に保つことを意識するのが良いかと思う。
2022/03/22 15:09
carolina04
ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成
2022/03/22 16:49
aktkro
一つ目書かないと永遠に書く気がおこらないのわかる
2022/03/22 16:55
rochefort
良い
2022/03/22 18:53
shior718
ありがてえ。
2022/03/22 19:12
lli
ありがとうございます。助かる〜
2022/03/22 20:12
remonoil
最初は簡易なアサーションに留めるのは同意だけど、それを模倣させると気付いた時にはそびえ立つ巨大な糞になってるのが悩ましい。やはり最適化は必須なんだよ
2022/03/22 20:32
kazokmr
最近フロントエンドの開発するようになったけどほぼ同意。例がロジックだけどUIならアクセシビリティも意識して書くようにしてる
2022/03/22 21:16
Nyoho
“今回は vitest を使う。mocha, ava, jest と今まで使った中で一番体験がいい。 API が jest 互換なので、移行しやすい。”
2022/03/22 22:02
uva
「複雑なアサーションを使うと、実装者は気持ちいいかもしれないが、第三者には読めない」
2022/03/23 00:01
kagehiens
参考になる……気がする。
2022/03/23 07:39
h_taiji
vitest使ってみる
2022/03/23 09:51
tkmkg8m
細かい方針は自分と考え方が違うけど、おおまかには同意。あとVitest知らなかったけどよさげね。
2022/03/23 11:39
fuyu77
"テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し……こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく"
2022/03/23 12:32
opera627
“ユニットテストは自分自身のために書いていて、それが結果として全体最適になる”同意
2022/03/25 09:48
mumei-0
“今回は vitest を使う。mocha, ava, jest と今まで使った中で一番体験がいい。 API が jest 互換なので、移行しやすい。”
2022/03/25 13:45
mizdra
良い。テストファイルをテスト対象のファイルと同じ場所に置くのは僕もやってる。テストの存在が身近になるので心理的に書きやすくすること、お手本となるテストを探しやすくすることが狙い。