See the Elephant

1992生まれのプログラマが書くエンジニアブログ

テスト駆動開発（TDD）はもう終わっているのか？ Part1を読んでリポジトリ層に関するMockについて思いをはせる

postd.cc

TDDとモックの話

  • Mockによって中間地点のゴールを作ることができるメリットがある

  • Mockを多用しすぎることでリファクタリングが難しくなる場合もある

mock多用のチームからmock使わないチームに異動したけど、個人的にはない方が楽やなと思う

過去の和田さん(t-wada)とのペアプロで

「現実を模したMockを作り実装を合わせるべきで、実装に合わせたmockを作るべきでない 」

と言われたことを覚えている

実装のあとにテストを行うと実装に引きずられたテストケースとMockを書きがち

これを追認のテストと呼ぶそう。

Mockが便利すぎた結果、実装を"許す"形でテストを書かないように気をつけなければいけない、とおっしゃってた

Mockがないと、現実の制約の中で戦わざるをえないのでそっちのほうが結果的に楽だなと思う

友人がt-wadaさんのツイートを教えてくれたので雑談

DBドライバのMockを"自作自演"と呼ぶのはとても腑に落ちて素晴らしい表現だと思う。

友人曰く、

なんでもかんでもモックするのはどうなんだろう？ という同じ疑問を持っていた

だそう。

自分的に以下のように考えている。

DB ドライバをモックにするとひたすら自作自演を行うテストになってしまうので、私は実際にデータベースとやりとりを行うテストを書きます。

あーもうほんとうにこれです。

前のプロジェクトはrepositoryをmockしてたけど、DBが返却しない値を設定できてしまうのでそれはあまり勧められた設計ではないなと思った

自分の開発マシンに入るものは常に本物を使い、入らないものだけモック/スタブを使います

めっちゃなるほどだ。。。

(友人) 今だとDocker とかで本番に近い環境整えることができるからなおさら本物を使ったほうがいいのかなーと思う

(自分) 今のチームだと実際にDB書き/読みにいくところまでテストされてますね

DBの制約とかDTOやビジネスロジックのテストとしてはそっちの方が明らかに利点あるなーと思います

友人の言う通り、今ならdockerでチームメイトに同じDB seedや環境を配ることができる。

そう思うとDBに対してはMockingせず、本物を使う方がいいのだろう。