テスト駆動開発(TDD)はもう終わっているのか? Part1を読んでリポジトリ層に関するMockについて思いをはせる
TDDとモックの話
Mockによって中間地点のゴールを作ることができるメリットがある
Mockを多用しすぎることでリファクタリングが難しくなる場合もある
mock多用のチームからmock使わないチームに異動したけど、個人的にはない方が楽やなと思う
過去の和田さん(t-wada)とのペアプロで
「現実を模したMockを作り実装を合わせるべきで、実装に合わせたmockを作るべきでない 」
と言われたことを覚えている
実装のあとにテストを行うと実装に引きずられたテストケースとMockを書きがち
これを追認のテストと呼ぶそう。
Mockが便利すぎた結果、実装を"許す"形でテストを書かないように気をつけなければいけない、とおっしゃってた
Mockがないと、現実の制約の中で戦わざるをえないのでそっちのほうが結果的に楽だなと思う
友人がt-wadaさんのツイートを教えてくれたので雑談
DB ドライバをモックにするとひたすら自作自演を行うテストになってしまうので、私は実際にデータベースとやりとりを行うテストを書きます。
— Takuto Wada (@t_wada) 2020年1月14日
以前 #fukabori ep.13 で話したのですが、私がテストで実物とモック/スタブを使い分けるルールははっきりしていて、自分の開発マシンに入るものは常に本物を使い、入らないものだけモック/スタブを使います(個人の意見です)https://t.co/f9vuAUayQK https://t.co/0rN6oVxmHw
— Takuto Wada (@t_wada) 2020年1月14日
DBドライバのMockを"自作自演"と呼ぶのはとても腑に落ちて素晴らしい表現だと思う。
友人曰く、
なんでもかんでもモックするのはどうなんだろう? という同じ疑問を持っていた
だそう。
自分的に以下のように考えている。
DB ドライバをモックにするとひたすら自作自演を行うテストになってしまうので、私は実際にデータベースとやりとりを行うテストを書きます。
あーもうほんとうにこれです。
前のプロジェクトはrepositoryをmockしてたけど、DBが返却しない値を設定できてしまうのでそれはあまり勧められた設計ではないなと思った
自分の開発マシンに入るものは常に本物を使い、入らないものだけモック/スタブを使います
めっちゃなるほどだ。。。
(友人) 今だとDocker とかで本番に近い環境整えることができるからなおさら本物を使ったほうがいいのかなーと思う
(自分) 今のチームだと実際にDB書き/読みにいくところまでテストされてますね
DBの制約とかDTOやビジネスロジックのテストとしてはそっちの方が明らかに利点あるなーと思います
友人の言う通り、今ならdockerでチームメイトに同じDB seedや環境を配ることができる。
そう思うとDBに対してはMockingせず、本物を使う方がいいのだろう。