Open TokiNoviceProgrammer opened 7 months ago
【pt実施時のjunitでのメリット】 ①テスト実行 ・既にテスト済みの不要なデータの削除→junitで自動化 ・テストデータの登録→junitで自動化 ・テスト対象のサービス以外はコメントアウト(直にソースに手を加える必要がある) →junitでテスト対象のサービスを呼び出すことで直にソースに手を入れることは不要 ・実行 ・DBから結果を取得→junitで自動化 ・取得結果を整形してエクセルに貼り付けて、1つずつ確認(各テーブル分実施)→assertEqual(期待値, 実施値)で1つずつ確認。確認のコストは同じだが、一度確認した部分は再度確認する際は自動化になる。 ②バグや仕様変更の修正 ・ソースを修正 ・影響のある箇所について、①を初めから実施→junitを使用すると再ptは自動化でコスト減 ③不足分テストの追加 ・網羅性を目視で確認(ソースやテスト仕様書から読み取る)→junitにてソースに色がつき、確認コスト減 ・不足分のテストケース追加し、①を初めから実施→影響する部分の再ptのコスト減、追加部分も必要箇所のみassertEqual(期待値, 実施値)を追加するのみであるためコストはかからない。 ④エラーメール送信機能など、その独自のサービスのみのテストがしたい場合、関係ないサービスなど部分をモック化して、本来テストしたいサービスのテストに集中可能
【pt実施時のjunitでのデメリット】 ・導入にコストがかかる →spring bootを使用していれば、既にjunitも内蔵しており、プラグイン導入や設定の追加などの作業は不要で、コストなしで使用可能 ・手戻り 既に手動で実施した箇所の手戻りが発生する →既に実施済みの部分はjunitでは対応せずに次のケースから進める運用にすればほとんど手戻りはない
【pt実施時のjunitでのメリット】 ①テスト実行 ・既にテスト済みの不要なデータの削除→junitで自動化 ・テストデータの登録→junitで自動化 ・テスト対象のサービス以外はコメントアウト(直にソースに手を加える必要がある) →junitでテスト対象のサービスを呼び出すことで直にソースに手を入れることは不要 ・実行 ・DBから結果を取得→junitで自動化 ・取得結果を整形してエクセルに貼り付けて、1つずつ確認(各テーブル分実施)→assertEqual(期待値, 実施値)で1つずつ確認。確認のコストは同じだが、一度確認した部分は再度確認する際は自動化になる。 ②バグや仕様変更の修正 ・ソースを修正 ・影響のある箇所について、①を初めから実施→junitを使用すると再ptは自動化でコスト減 ③不足分テストの追加 ・網羅性を目視で確認(ソースやテスト仕様書から読み取る)→junitにてソースに色がつき、確認コスト減 ・不足分のテストケース追加し、①を初めから実施→影響する部分の再ptのコスト減、追加部分も必要箇所のみassertEqual(期待値, 実施値)を追加するのみであるためコストはかからない。 ④エラーメール送信機能など、その独自のサービスのみのテストがしたい場合、関係ないサービスなど部分をモック化して、本来テストしたいサービスのテストに集中可能
【pt実施時のjunitでのデメリット】 ・導入にコストがかかる →spring bootを使用していれば、既にjunitも内蔵しており、プラグイン導入や設定の追加などの作業は不要で、コストなしで使用可能 ・手戻り 既に手動で実施した箇所の手戻りが発生する →既に実施済みの部分はjunitでは対応せずに次のケースから進める運用にすればほとんど手戻りはない