LaravelのリポジトリパターンおよびDBを使用したテスト方法についての

Question

Laravelにおけるリポジトリパターンについて教えてください。
リポジトリパターンのメリットは以下の2点と認識しています。

Laravel5のアーキテクチャから学ぶより良いクラス設計 - Qiita

● オブジェクトアクセスに関する設計上の決定を伝える。
● テストで使用するために、ダミーの実装で置き換えるのが容易になる（インメモリコレクションを使用するのが一般的）。

その上で、現在以下の3パターンのどれで開発を行うか迷っています。
それぞれ回答いただけるとありがたいです。

1. インターフェースをインジェクション

ytake.blog | Laravel/データベースレイヤーとのテスト1

このやり方が一番美しいなと思いました。
大規模開発において、このパターンが一般的に使われていますか？

2. よく使うメソッドをインターフェース化

GitHub - phanan/koel: ????A personal music streaming server that works.

getOneById, getByIds, getAllのみRepositoryInterfaceで定義されています。
コントローラーにインジェクションしてるのはRepositoryクラスなので、Eloquentを変更するとなった場合は、各リポジトリクラスのEloquentを使っているメソッドを修正していく必要がありますか？

この方法の利点があまり分かりませんでした。。

3. sqliteのインメモリを使ってモック化しない

個人開発で大きな仕様変更がない場合はこの方法が一番メリット大きいでしょうか。
シーダーと、sqliteのインメモリを使いデータベースにアクセスできるようにしておけば、テスト時の速度面でも気にならず、そもそもモック化しなくていいと思いました。
認識合っていますか？

以上、よろしくお願いいたします。

Answer 1

Laravelなら規模に応じて3か1。

DBのテストのこともドキュメントに書いてるようにテスト時にDB使うななんて強制してない。
DB使うべきではないなんてのはLaravel以前の常識による思い込み。
テストが増えればインメモリSQLiteでも遅くなるし、SQLite限定の微妙な仕様の違いもあるけど、結局は実際にDB使ったテストしたほうが確実。
https://readouble.com/laravel/5.7/ja/database-testing.html

インメモリでも遅いレベルになったらリポジトリパターン。
Laravelのサービスコンテナを理解してないと誰かの真似するだけになって失敗するけど。
リポジトリパターン使ってる上級者は他の部分も無駄に複雑なことしててて普通にLaravel使いたい人は参考にならない。

DB変更しやすいとか言われてもそもそもDBの変更なんてしないし…。
MySQLからPostgreSQL程度ならEloquentで吸収できるだろうし。
低確率な将来のために無駄な努力してる。
そこまで考える必要がある規模かどうかでプロジェクトごとに判断するしかない。

・現実で見た例
リポジトリパターン使ってるのにサービスコンテナもSQLiteも使ってない。
Docker使ってるとはいえDBサーバー起動してないとテストできない。
Laravelでこれはたぶん一番最悪なパターン。
元は別のフレームワーク使ってた会社がLaravel指名されたのでLaravelで作ったけどLaravel流を覚える気が全くないまま作るとこうなるんだろうな、という感じの中身だった。

Comments

[matometaru]

ありがとうございます。
理解できました。