なんとなく「テストが全部通れば完璧だよね〜」って思ってたけど、よく考えたらちょっと違うかもって気づいたんだよね😳💭
わたしが最近、いくつか「完璧にパスしてるテスト」を書きながらハッとしたことがあってさ。テストって、実はコードが正しいことを証明してるわけじゃなくて、コード同士が「こう動くはず」って思ってることが一致してるだけなんだよね✨
よくある例で言うと、
- 実装したコードが「こう動く」って思ってて
- 書いたテストも「こう動くはず」って思ってる
でも、もしその「こう動く」が間違った前提だったら？
テストは全部パスしちゃうけど、実は変な動きのまま…ってことも普通にあるんだよね🥺
つまり、テストが全部グリーンのチェックマークでも、偽りの自信を持ってるだけかもしれないってこと。
これ、なんか怖くない？😱
だから最近はちょっと考え方を変えてみたんだ。
テストって、「正しさの証明」じゃなくて、「これがこう動くはず」っていう意図を固めておくものなのかなって。
要は「もしこの動きを変えたら教えてね！」って守ってもらうための目印みたいな感じ✨
でもまた厄介なことに、その「意図」自体が間違ってることもあるんだよね。
だからテストを書いても、それを鵜呑みにするのは危ない気がする…🤔
わたしはまだまだテストの意味や使い方に迷いながら書いてるけど、
もしみんなだったらどう思う？
テストって「コードの正しさの証明」？それとも「仕様のドキュメント」？あるいは「カオスを防ぐガードレール」？🛤️💡
なんかもっといい付き合い方があったら教えてほしいな〜って思ってるところ✨
はてな
コメント
リリー
「プログラムのテストはバグの存在を示すには有効だけど、不在を証明するのは無理だ」―ダイクストラ
ハンナ
要件通りに動いても要件が間違ってたら、コードや開発者のせいじゃないよね。
キンバリー
テストは「こう動くはず」という期待を定義して、それが破られたらすぐわかる仕組みだと思おう。
ミア
テストが通ったから正しいとは限らないし、失敗したから絶対に間違いとも限らない。 期待の変化を教えてくれるフィードバックなんだ。
クリス
だから統合テストや受け入れテストが最重要。 顧客の立場で使って評価すれば、要件が合ってれば正しく動いてるとわかる。
ロバート
良いテストは縛りじゃなくて、正しい方向に導くガードレールみたいなもの。
ジョージ
「コードが思った通りに動く証明」って違うよ。 テストは自分が思う通りに動くか、要件を満たしてるかを証明するもの。
サム
ポイントは「自分」なんだ。 AIにテスト書かせてるの？
グレース
意図を固定するのは自分だけじゃなくて、他の開発者にも分かるようにするため。 要件を守るためのものだよ。
サラ
テストは要件を確認して、複雑なシステムの使い方や動きをみんなが理解できるようにする。 新しいコードベースに触る時はまずテストを動かしてチェックするけど、テストがダメだと先が不安になる。
マックス
ドキュメントは検証じゃないし、完成した瞬間からズレてることも多い。
リリー
テストは将来の変更で要件が壊れないように守る役割もあるし、ドキュメントが描く動き通りにシステムが動いてるか確かめるもの。
クロエ
あと、「直さないバグは機能の一部」という話に近いけど、バグが長く残って依存されると後方互換性を保つ必要が出るから、そのバグの挙動にテストを書くことも考えたほうがいい。
ハンナ
常に失敗するテストを放置するのはダメだし、直さないバグは本当にバグなのか怪しい。
ロバート
テストは要件に合わせて書くべき、という長文投稿だよ。
グレース
テストをひとまとめに見ても意味ない。 論理動作確認、プロジェクト要件適合、内部要件適合、コードパス網羅、回帰検出など目的は色々で、一つのテストに全部求めるのは間違い。
キンバリー
あと、失敗するテストを書くTDDを知るといいよ。 今は面倒であまりやらないけど、テストが失敗することを確認するのは大事な考え方で、何を検証してるか考えさせてくれる。
マックス
この言葉は真実だけど、あんまり意味がないとも言える。
リリー
でもテストが無意味ってわけじゃないよ。 経済学専攻の知識を人生の全てで試せないけど、経済学に限れば十分ってのと同じ。
エイダン
OPはブログ宣伝のAI作成投稿が一つだけ。
レオ
バグを直したらテストが何個も落ちるのは、テストがそう書かれてるからだよ。
ハンナ
テストは本当に必要な部分だけをチェックして、変更で大事な所を壊してないか確かめるためにあるのに、「99.9%カバレッジ必要」ってバカな考えで無駄に全部の行をテストしすぎて、バグ直すだけでテスト修正が山ほど必要になる。
サム
そんなにテスト直させて自分の変更が正しいってどう信じろと？
ロバート
テストは機能やその前提、要件を固定するもの。
ミア
後から新人が壊しても、テストが壊れれば真っ先に警告してくれる。
グレース
でも新人がテストも変えて審査通しちゃったら、チームに根本的な問題がある。 テストはそのうちの小さな問題。
クリス
テストの目的はジョン・カーマックやドナルド・クヌースが作った完璧な証明じゃなくて、新機能開発中に誰かが要件を破ったら教えてくれる警報みたいなもの。
サム
レビューが悪い、統合テストなし、QAはボタン押すだけならテストは助けにならない。
エマ
でもテスト無しは断然ヤバい。 経験あるけど地獄だよ...
ハンナ
コードカバレッジ要求はマジで嫌い。 PRのレビューが雑だと、テストはカバレッジ稼ぎのだけの無意味なものになりがち。
キンバリー
テストが役立つかどうかは、
キンバリー
1. 要件に沿って先にテストを書く（TDD）ことで、自分のコードや仮定をただ肯定するだけじゃなくなる。
キンバリー
2. ビジネス側がテストを書いたり見たりできるように、cucumberやgherkinが生まれた。 これでテストとビジネス要件が繋がる。
キンバリー
だからテストは最初に書くんだ。 テストが機能の定義で、通れば実装完了。 失敗するテストがもう思いつかなければ完成。
ロバート
あとはテストが仕様を壊す変更をキャッチしてくれる。
