フロントエンドとバックエンドを分けるとどうなるか
ビジネスロジックテストの観点から
SPAやマイクロサービスのような、Webアプリをフロントエンドとバックエンドに分けるアーキテクチャには、副次的にビジネスロジックのE2Eテストが可能になる利点があることに気づきました。当然の話なのかもしれませんが、せっかく気づいたので、つらつら書いてみます。
分けないとユニットテストしかできない
まず、フロントエンドとバックエンドを分けない、いわゆるモノリシックなWebアプリについて、ビジネスロジックのテストをしたくなったと仮定してみます。
その場合、モデルに代表されるビジネスロジッククラスのユニットテストを実施するしかありません。他のクラスをテストしても目的が果たせないからです。
分けるとE2Eテストもできるようになる
一方、フロントエンドとバックエンドを分けるアーキテクチャだとどうでしょうか。
その場合、ビジネスロジックであるWeb APIに対してE2Eテストが可能になります。内部構造を知らなくても、APIの仕様がわかればテストが書けるわけです。
もちろん、E2Eテストが可能になったとしても、ユニットテストが不可能になるわけではありません。テストの手段が増えるだけです。
E2Eテストは言語に依存しない
E2Eテストには、ユニットテストと違って、言語に依存しない特長があります。APIを別言語で書き直す場合でさえ、テストケースが無駄になりません。
また、テストケース自体、どんな言語で書いてもかまいません。GoのAPIに対してPythonのテストを書いてもよいわけです。
Web APIのテストは保守コストが低い
別言語での書き直しほど極端な例でなくても、リファクタリングのためにユニットのインターフェイスを変えたくなることぐらいはあるでしょう。インターフェイスが変われば、ユニットテストのテストコードも修正する必要があります。
一方、Web APIのインターフェイスは気軽には変えられません。ころころ変わると、クライアントが困るためです。インターフェイスが変わらなければ、テストコードを修正する必要もありません。
ゆえに、ユニットテストよりWeb APIのテストのほうが保守コストがかからないといえます。
まとめ
まとめると、下記のようになります。
- フロントエンドとバックエンドを分けるアーキテクチャを採用すると、Web APIのE2Eテストが可能になる
- E2Eテストは言語に依存しない
- Web APIのテストは保守コストが低い
そのようなアーキテクチャを採用するのであれば、せっかくのメリットを活用すべきだと思います。
なお、本稿をまとめるにあたっては、下記の記事が参考になりました。
どちらも2014年の記事です。5年経った今でも納得できる内容でした。
