2,085件のテストが、玄関のドアを開けるものは1つもない

2,085 Tests, and None of Them Opens the Front Door

2,085件のテストが、玄関のドアを開けるものは1つもない

開発者が自身の22のリポジトリを調査したところ、2,085件のテストケースが存在するにもかかわらず、継続的インテグレーションでテストを実行しているのは1つだけで、デプロイを防ぐテストはほぼ皆無でした。テストの多くはソースコードを読むことで検証できる不変条件をチェックするもので、ブラウザテストは存在しません。著者は、テストとデプロイの配線が欠如していることが真の問題であり、プレーンな英語で書かれたE2Eテストがこのギャップを埋める可能性があると論じます。

テストが何も実行されないということは、それはドキュメントである。
  1. simonreiff

    正直に要約すると、平易な英語のエンドツーエンド層は、実在するが現在は空いている層を埋めるものであり、およそ2000件の高速な決定的テストの上に位置し、ブラウザツールではできない仕事をする。その文の両半分は重要な意味を持つ。前半だけを言うベンダーは、私のようなコードベースを読んでいないと言っているに等しい。

    このような記事を投稿する人は、自分の記事も書いていないし読んでもいない。あるいは自分のコードベースもだ。つまり、この人は自分が書いたわけでもないコードベースで問題に遭遇し、それも読んでいないようで、今度はそのゾンビコードベースについての記事をみんなに読んでほしいと思っているが、投稿前にその記事も書いていないし読み返してもいない。

    著者へ: あなたの記事は次のように数文で書き直せる。「私はvibe codingでコードベースを作り、Claudeに大量のユニットテストを追加するよう頼んだ。コードもテストも読まなかった。ただ動いてほしかっただけだ。しかし、テストをCI/CDパイプラインに組み込むよう頼むべきだと知らなかったか、それが何か知らなかったか、あるいは知っていたが実際にそうなっているか確認するのが面倒だった。とにかく、いい教訓を学んだ: localhost:3000で起こったことはlocalhost:3000に留まる。.github/workflows/cicd.ymlファイルを設定してテストを取り込まないと。そうしないと、実際にはあまり役に立たない。学んだぞ!」そして、わかってる?それがどんなに陳腐であっても、その記事をもっと楽しめただろうに。たった5分なんだよ。たったの5分。

  2. perrygeo

    逸話を一つ: 私はユニットテストに熱心で、それだけにこだわるシニア開発者と一緒にプロジェクトで働いたことがある。ソフトウェアは、モックだらけの小さなレゴブロックのように完全にテストされなければならなかった。「すべての部品が正しければ、組み合わせも正しいはずだ」というのが彼の言葉だった。(彼は創発的な振る舞いを考慮したことがなかったのだろう)

    統合テストやE2Eテスト、手動テストへの断固たる反対と、ユニットテストの完全なカバレッジへの熱心な主張の後、シニア開発者が変更をデプロイした... ドカン。プロセスは開始数分後にメインのバグで激しく失敗した。完全な本番障害だ。目で見て明らかなバグだった。明らかに、機能を開発していた数週間、彼はアプリケーションを一度も実行しようとしなかった。各部分は単独では完全に磨かれていたが、アプリケーションに統合されたときには完全に失敗した。

    私が考えるようになったのは: ユニットテストはライブラリ向けであり、すべての入力と出力をきれいに定義できる閉じた世界だ。統合テスト/E2Eテストはアプリケーション向けであり、システム思考、証明ではなくシミュレーションを必要とする開かれた世界だ。自分がどの世界で働いているかを知ることだ!

  3. netsharc

    ざっと目を通した。見出しの一つに「ギャップはカバレッジではなく、配線だった」とある。AIが書いたような雑な感じがして、読む気にならない...

    以前はHNのあらゆるものを読んでいたが、質の低いものへのアレルギーでやめてしまった。それは良いことだと思う?

この日のほかの記事

2026-08-17