【ITニュース解説】Testing the Service Layer - Part 1: What the Generic Suite Owes Every Service (Chapter 10)

この解説では、ソフトウェア開発における「サービス層」と呼ばれる部分のテスト、特にビジネスロジックのテストについて深く掘り下げる。サービス層とは、アプリケーションの中心となるビジネスルールや処理の流れを管理する部分のことで、データベースの操作やユーザーインターフェースとは切り離して設計されることが多い。これを「クリーンアーキテクチャ」と呼ぶ。このように設計することで、サービス層のコードは、データベース（例えばHibernateやSQL）やウェブ通信（HTTP）といった具体的な技術に依存せず、純粋にビジネスロジックに集中できるため、非常に高速かつ独立したテストが可能になる。

しかし、このようなテスト戦略には落とし穴もある。例えば、ある機能のテストコードで、オブジェクトの識別子（ID）をデータベースが割り当てるように見せかけるモック（偽物）の動作を作成していた。当初はコメントアウトされていたこのID設定のコードが、実際に問題を引き起こした。具体的には、テストが成功し続けていたにもかかわらず、そのIDが実際には設定されていなかった。原因は、ドメインオブジェクト（ビジネス上の実体を表すオブジェクト）のIDが、一度設定されると変更できない「不変（final）」という性質を持っていたため、テストコードがIDを設定しようとしてもコンパイルすらできなかったことにある。この問題は、テストが実際のデータベースの振る舞いを正しく模擬していなかったことを示している。本当のデータベースは、IDを持たない新しいオブジェクトを受け取り、IDを割り当ててからその新しいオブジェクトを返す。しかし、このモックは、受け取ったオブジェクトに直接IDを設定しようとしていた。これは、テストが「本来確認すべき契約（データベースがIDを割り当てる仕組み）」を正しく守らず、「テストが通りやすいように契約を都合よく書き換えてしまっていた」という本質的なバグだった。

このような誤ったテストの振る舞いは、共通のテスト基盤を通じて、それを継承するすべてのサービスに伝播してしまう。まるで遺伝子のように、意図せずして間違いが広く行き渡ってしまうのだ。しかし、この「継承」という仕組みは良い方向にも働く。一度正しく修正すれば、その修正が継承しているすべてのサービスに自動的に適用され、個々のサービスを変更することなく、正しい振る舞いを獲得できる。

ここで疑問に思うかもしれないのは、「なぜデータベースのモックを使うのか」ということだ。テストのために本物のデータベースを用意する代わりに、メモリ上の簡易データベースを使う方法もある。実際に、永続化層（データベースとのやり取りを管理する層）のテストでは、メモリデータベースが有効な場合もある。しかし、サービス層のビジネスロジックをテストする場合、メモリデータベースを使うと、サービスロジックの正しさと、データベースのマッピングやSQLクエリの正しさという、二つの異なる側面を同時に検証してしまう。もしテストが失敗した場合、ビジネスロジックが間違っているのか、それともデータベース関連の設定が間違っているのか、原因の特定が難しくなる。

一方、DAO（Data Access Object、データベース操作を抽象化するオブジェクト）をモックする場合、サービス層はデータベースから完全に切り離される。モックは、開発者が「こう振る舞ってほしい」と設定した通りにだけ動作する。これにより、純粋にサービス層のビジネスロジックだけを検証でき、データベースの細かな挙動に惑わされることなく、ビジネスルールが正しく実装されているかを確認できる。このアプローチの欠点は、モックの振る舞いが実際のデータベースの振る舞いと乖離してしまうリスクがあることだ。モックが実際のデータベースの契約と異なる振る舞いを定義している場合、テストは成功しても、実際のアプリケーションでは問題が発生する可能性がある。このリスクを軽減するためには、モックが模倣する実際のDAOの挙動を、永続化層のテストや開発者によるレビューを通じて継続的に検証する必要がある。

共通の抽象テストスイートは、新しいサービスが作成された際に、基本的なCRUD（作成、読み取り、更新、削除）操作のテストを自動的に提供する。例えば、create()メソッドのテストでは、リクエスト元のIDがnullでないかを確認した後、作成者IDと更新者IDをドメインオブジェクト自身に設定してから、データベースに永続化する。このとき、単にメソッドの戻り値を検査するだけでなく、「ArgumentCaptor」というツールを使って、DAOに渡される直前のオブジェクトの状態をキャプチャし、所有者情報が正しく設定されていることを確認する。これは、セキュリティ上の重要な考慮事項である。もし、データベースに保存された後に所有者情報が設定されるような実装になっていた場合、一時的に所有者のいない不正なエンティティが存在する期間が生じてしまう可能性がある。ArgumentCaptorを使うことで、このような時間的な区別を明確にし、潜在的なセキュリティホールを防ぐことができる。

また、IDが不変である設計のため、モックがデータベースによるID割り当てをシミュレートする際には、受け取ったオブジェクトを直接変更するのではなく、新しいIDを持つ新しいインスタンスを作成して返す必要がある。これは、withId()というヘルパーメソッドを通じて実現される。

update()メソッドのテストでは、「authorize()」という承認チェック機能が、更新対象のエンティティ全体を受け取るように設計されている点が重要だ。これにより、承認チェックのためにエンティティをデータベースから再度読み込む必要がなくなり、一度のデータベースアクセスでエンティティの取得と承認チェックの両方を行える。これは、テストコードでverify(getMockDao(), times(1)).loadById(...)という形で、「loadByIdが一度だけ呼び出されること」を検証することで、意図しない二重読み込みを防ぐアーキテクチャ上の保証となる。

さらに、update()テストでは、作成者ID（createdById）が、更新処理によって誤って変更されないことを確認するテストも含まれる。更新用のデータ転送オブジェクト（DTO）がcreatedByIdフィールドを持たないからといって、共有されるトランスフォーマー（データを変換するロジック）が将来的にそのフィールドをリセットするような変更を加えてしまう可能性もゼロではない。このような共有コードにおける意図しない変更は、多くのサービスに影響を及ぼすため、それを防ぐための予防的なテストは非常に価値がある。

delete()メソッドは「冪等性」を持つように設計されている。これは、何度削除操作を実行しても結果が同じであることを意味する。つまり、存在しないエンティティを削除しようとしても、エラーにならず、単に「何もしなかった」という結果になる。このテストは、データベースがエンティティを見つけられない場合でも例外を投げず、実際に削除操作が呼び出されないことを検証する。

数値の比較についても重要な注意点がある。BigDecimalという型で金額などを扱う場合、equals()メソッドではなくcompareTo() == 0を使うべきである。equals()は数値の「表現形式（スケール）」まで比較してしまうため、例えば「239.99」と「239.990」は同じ金額を表していてもequals()では異なる値と判断されてしまう。compareTo() == 0は純粋に数値が等しいかどうかを判断するため、金額比較の際には常にこちらを使用することが正しい。

これらの共通のテストスイートを通じて、基本的なCRUD操作に関する多くのガードや承認ルールが一度書かれるだけで、それを継承するすべてのサービスに適用される。これにより、開発者は各サービス固有のロジック（例えば、changeStatus()のような特定の状態変更処理）に集中できるようになる。共有できない固有のロジックについては、それぞれのサービスで個別のテストが必要となる。この仕組みは、コードが進化する際に、変更すべきものが明確になり、不要な部分が影響を受けずに済む、柔軟なソフトウェア開発を可能にする。

最終的に、このアプローチは、アプリケーションの中心的なビジネスロジックを、高速かつ信頼性の高い方法でテストするための強力な基盤を提供する。それは、モックを賢く使い、継承の力を活用し、潜在的な落とし穴を事前にテストで捉えることで実現される。信頼性の高いテストスイートは、将来の変更に対してアプリケーションの堅牢性を保証し、予期せぬバグの発生を防ぐための不可欠な要素なのだ。