DBなど副作用が絡む場合の自動テストをどう行うか

Question

タグにはGo、Rust、Haskellと入れさせていただきましたが、それに限らず静的型付け言語でテストを行うにはどうすれば良いのかを考えています。方針的には2つあるかと思います。

• 副作用の薄いラッパーを作り注入して、テスト時はモックと差し替える
• 本番と同じコード（副作用をそのまま）を書いてテスト環境を作ってテストする。

前者のほうが実装としてはスマートですがやはり手間がかかります。それにDockerで気軽にコンテナを立てられたり、クラウド環境もコード化できている昨今の事情を考えると後者の手法でも良いのではないかと思っています。

おそらくベストプラクティスのでない問ではあるのでしょうが、実際現場でのテストコードの運用を踏まえた上でどうするのか良いかご教授いただければと思います。

Answer 1

「動的静的型付け言語で」と限定する意味がよくわかりませんが、単体テストと統合テストを混同してる気がする。

単体テスト→モックを使う
統合テスト→テスト用DBを使う

のがふつーじゃないかと。

そもそもテストするフェーズそのものが違うので、本番と同等のDBまで作って、そこへ接続してテストできるぐらいまでコードを作り込んでから全部ガッチャンコしてテストする、という発想がナシじゃないかと思いますが。

Comments

[A_kirisaki]

「静的」です。そこに限定したのは型のせいでモックが作りにくいという事情があります。そして質問で述べたように昨今のような事情なら結合テストでやるようなものも単体テストレベルでやってしまった方が楽なのではないか、という疑問もあります。

[gentaro]

あ、打ち間違いです。失礼。
テスト対象のシステムの規模が小さいとか、個人開発でやるんだったら好きなようにすればいいと思いますが、大規模開発になると事情は異なってくるでしょう。
テストを自動化する意味というのは、繰り返し何度も気軽にテストを回し、バグが発生した場合は直ちに原因を特定するためにあります。
システムの規模が大きくなると、ちょっとしたコード修正のたびにDBまで貫通したテストを毎回回すというのは速度面でも現実的じゃないですし、誰のどの修正が影響しているのか、という点でも見通しが悪くなります。
また、テストしたい観点も単体テストと統合・システムテストレベルでは異なってくるはずで、パフォーマンスやミドルウェアのトラブル時のテスト等、非機能要件に関わるものもありますが、そういうテストとある関数の閾値を意識したテスト、みたいなものは全く性質が異なりますし、全部一気にやる必要はありません。

[A_kirisaki]

そうですね、規模によってもこの辺も変わってきそうな感じがします。
大規模な開発に携わったことがないのでその観点が抜けていました。
単体テストと結合テストの違いをもっと意識しようと思います。

Answer 2

煮え切らない回答ではありますが、自分なら以下の観点を考慮しながら都度判断します。

• （モックできる仕組み、あるいは逆にテスト用DBを用意するスクリプトなどの）実装・メンテコスト
• テストの実行にかかる時間
• 自動テストで何を保証したいか（これが一番大事）

Comments

[A_kirisaki]

> 自動テストで何を保証したいか

まさしくその視点が抜けていました。そもそもテストで何を保証したいのかをよく考えるべきだったようです。

Answer 3

ネットワーク接続をしない、メソッド単位のいわゆる単体テストレベルの確認を実施するのであれば、DBなどの外界へのアクセスはinterfaceを切って、モックを生成することが多いと思います。
Goだと golang/mock を使っているケースをよく見ます。もちろん自前でモックを作成しても問題はないです。

localhost内のネットワーク接続を伴うようなE2Eテストであればdocker-composeなどを用いてコンテナのDBにデータを格納してテストするケースが考えられます。

※自動テストが何を指すのか明確ではないですが、Pull Request が発行されたときにテスト実行して、その結果をフィードバックする、くらいに考えています。

自動テストでテストしたい内容にもよると思いますが、実際にSQLが発行され、その結果が正しいことを自動でテストしたいのであれば、後者のdockerなどのコンテナのDBをテストに用いることが多いのではないでしょうか。

---

(自動テストとは別に、別途テスト環境を構築してテストされることは必須かと)

Comments

[A_kirisaki]

やはりある程度の規模を見込むのならばモックの利用が現実的のようですね。
golang/mockについては調査のときs目につけていたのでもっと深く調べてみたいと思います。