要約

  • 生成されるテストはモダナイズ後のコードを対象とし、元の機能が維持されたことを検証するものではないと資料に明記されている。
  • 既存テストの移植、新規テスト、ローカルのビルド検証、実行時の受け入れは、別々の証拠になる。

移行の完了を判断するとき、テストが増えたことと、必要な動作が残ったことは分けておきたい。AWS は９月10日、Transform for .NET に単体テストの生成機能を追加した。テスト可能性を評価し、対象のクラスやメソッドを計画して、業務ロジックやコントローラーなどにテストを作る。AWS Toolkit for Visual Studio で選択できる機能だが、購入者が確認すべきなのは新しい成果物の証明範囲である。

単体テストの説明は、この範囲を明確に限定している。テストはモダナイズの後に生成され、元のコードの機能がモダナイズ後にも保たれたかを検証するものではない。新コードを後から変更するときの回帰確認には役立っても、記録されていなかった以前の期待動作を自動で取り戻すわけではない。

既存のテストは別の扱いだ。対応する MSTest、NUnit、xUnit のプロジェクトは移植され、実行結果が報告される。以前に書かれた期待を、変更後にも確認する経路になる。ただし、元のテストが網羅的だったことや、全業務条件が含まれていたことまでは証明しない。新しく作られたテストは補足であり、本数が増えても変更前の基準に変わるわけではない。

生成を選ぶ時点も重要になる。ジョブ開始時に有効化した場合、生成したテストはローカルのビルド検証に含まれる。変換後の対話で生成を依頼した場合は、すでに終わったその検証には含まれない。後者では、変換後にコードを調整してからテストを作れる。後で実行できないという意味ではなく、過去の成功結果で未来の成果物を証明できないということだ。

引き継ぎには、テストの由来と対象リビジョンを残したい。何を移植し、何を新しく書き、どのコードを検証し、何が未実行なのか。「テスト成功」の合計だけでは区別が消える。カバレッジの数字だけで、テストに書かれた期待が顧客の必要な結果と一致するかは決まらない。

AWS の変換前の推奨事項も、動作、見た目、セキュリティ制御、業務ロジック、データ保存を考慮した検証計画を求める。また .NET のモダナイズとアプリケーションのアーキテクチャ変更を区別する。テスト生成を購入したことで、約束した作業範囲が暗黙に広がったり、必要な検証が消えたりするべきではない。

仕上げの手順では、報告書を読み、アプリケーションを実行し、機能や画面の振る舞いが元と一致するかを確認する。良い数値が出た後の形式的な手続きではなく、コード納品をサービスの受け入れにつなぐ作業だ。今回の発表は自動化の能力を示すもので、実際の本番移行完了、受け入れ工数や不具合の削減量を立証したものではない。