実際にやったDBの自動テスト方法
https://needtec.exblog.jp/19090632/
データベースを使った自動テストについて
https://gist.github.com/taichi/3834450
開発・テスト用DB環境の管理と自動テストの考察
https://qiita.com/mima_ita/items/45205cdbce3deeee89c6
第3回 自動テストと継続的インテグレーションを既存プロジェクトへ導入しよう
https://gihyo.jp/dev/serial/01/mixi_socialapp/0003
大規模業務システムにおける再利用可能なテスト自動化の取り組み
http://jasst.jp/symposium/jasst17tokyo/pdf/D4-1.pdf
Laravelで発行されたSQLをUnitテストで確かめる
https://qiita.com/mpls104/items/9905357dba17853b3f63
- テストコードにはWhatを記載せよ
- ドキュメントとしての役割
- 主にデバッグ用途でDBテストを行う
- 変更が多い機能や、サービスのコアになる複雑な機能には自動テスト導入
初心者がテストコードを書くようになった経緯とオススメのテストフレームワーク
https://www.infiniteloop.co.jp/blog/2014/03/beginners_test/
やはりお前たちのRepositoryは間違っている
https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf
- Repositoryパターン
- メリット
- Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになる
- データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離せる
- 注意点
- 状態更新に関わる振る舞いはEntityやServiceに実装
- 状態の操作に関する処理は可能な限り可視性を制御して無理やり変更が出来ないようにする
- 子テーブルごとにRepositoryを作ってしまうとチェック処理等のビジネスルールが散らばって不具合を作りこむ原因になる
- 複雑なクエリをRepositoryで頑張って発行しない。パフォーマンスの問題や
- 集約に対する操作は必ずRepositoryを介して行うべきだが、変更の操作を行うときだけ。複雑な参照の場合はRepositoryに実装せず、アプリケーションレイヤで実装してOK。
- アプリ固有の複雑な処理はQueryService、エンティティの永続化や取得はRepositoryという風に責務を分離することで、不要にRepositoryが複雑化することを避けることができる
- メリット
集約の設計と実装
https://speakerdeck.com/j5ik2o/ji-yue-falseshe-ji-toshi-zhuang
15年続くWebサービスへのCI/CDとテストコードの導入
https://speakerdeck.com/9bo9bo/cdtotesutokodofalsedao-ru