システムテストが失敗しました

を導入したとき、 システムテストのデフォルト設定 2016 年に Rails 5.1 に登場したとき、私は大きな期待を抱いていました。 理論的には、実際のインターフェイスを通じてヘッドレス ブラウザを駆動するシステム テストにより、マシン全体が正常に動作しているという確信度が高まります。 また、ブラックボックス方式で実行されるため、実装の変更に対する耐性がより高くなります。 しかし、残念ながら、実際にはこれらのどれもが真実ではないことがわかりました。 システム テストは、10 年前と同様に遅く、脆弱で、偽陰性が多いままです。この倦怠感にはさまざまな理由があると思います。 ブラウザは複雑で、JavaScript によって駆動される UI はタイミングの問題が発生しやすく、ブラックボックス テストが失敗した理由を解明することは、多くの場合、驚くほど困難です。 しかし、私にとっての結論は、システム テストはほとんどの場合、労力を費やす価値がなくなっているように見えるということです。 別の言い方をすれば、バグを捕らえて利益を得るよりも、システム テストを確実に動作させるためにはるかに多くの時間を無駄にしているということです。これが、私たちがテストを自動化する理由の核心になります。 変更に関する迅速なフィードバック ループのためにこれを行います。また、リグレッションを検出するためにも行いますが、何よりも、システムが機能するという確信を得るためにこれを行います。 これらはすべて有効な目標ですが、システム テストがそれらを達成するための最良の方法であるという意味ではありません。私は、システム テストをすべて放棄することを推奨しているわけではありません。 おそらくほとんどの人がそうでしょう。 システム テストは、トップレベルのスモーク テストに適しています。 エンドツーエンドであるため、ドメイン モデルやビジネス ロジックの問題ではなく、システムの正確な読み込みをまったく妨げている構成や対話の問題が検出される傾向があります。 早くて安く手に入るのは良いことです。ただし、最も厄介な点は、ビジネス ロジックのテストではなく、どのモデルとコントローラーのテストがより良く、より安価に実行できるかということではなく、UI…