私のキャプション幅ガードは全てのテストをパスしました。それは... ノート

私のキャプション幅ガードは全てのテストをパスしました。それはレンダラーが描画しなかったテキストを測定していました。

字幕のセグメンテーションが不十分であるというユーザーからの苦情が、新たな微妙な問題を引き起こすバグ修正につながりました。元々の問題は、字幕が文の構造を無視して固定の単語チャンクに分割されていたことでした。これにより、文の途中で切れるなど、意味不明な分割が発生していました。修正では、句読点を尊重し、チャンクあたりの単語数を特定の値にすることを含む、より良いチャンク分割のためのルールが実装されました。重要な追加機能は、レンダリングされたチャンクが画面に収まるようにするためのピクセル幅の上限でした。この幅の上限は、実際にレンダリングされたテキストの幅を測定することを意図していました。しかし、テキストの幅を測定するコードは、測定前にテキストを誤って大文字に変換していました。これは、視覚的なスタイルを意図してすべて大文字を使用するビデオパイプラインの別の部分からステップを借用したためでした。選択されたフォントでは、大文字のテキストは混合ケースのテキストよりも幅が広くなります。測定は大文字に変換された入力に対して正確でしたが、実際の字幕は元の混合ケースでレンダリングされていました。この不一致により、幅の制限はテキストがはるかに広いと判断し、不要な分割を強制しました。これにより、最初の問題よりも悪いユーザーエクスペリエンスである1単語のチャンクが作成されました。重要なことに、幅測定関数は受け取った入力(大文字に変換されたテキスト)に対して正しく動作したため、すべての自動テストは合格しました。テストでは、測定されたテキストが実際に画面にレンダリングされたテキストと一致するかどうかを確認しませんでした。このバグは、レンダリングされたビデオを視聴していた人間によってのみ発見されました。この状況は、一般的な落とし穴を浮き彫りにしています。つまり、テキスト変換のような仮定に合意することになっている、本番環境と検証用の別々のコードパスです。これらの仮定がずれると、自動テストが見逃す微妙なバグが出現します。著者は、パス間で変換関数を共有すること、または実際にレンダリングされた出力を定期的にサンプリングして検査することを緩和策として提案しています。人間の監視なしにテストスイートのグリーンのみを信頼すると、このような微妙な乖離が気づかれずに存続する可能性があります。