こちらを読んで個人的に少し整理がつかなかった部分のまとめ
Dependency Injection(DI)とは
直訳は依存性の注入
抽象化されたオブジェクトに、外部からオブジェクトを入れて振る舞えること。
ここでいう振る舞いとはインスタンス化できること。ともいえる。
この本ではテストデータをテスト対象のオブジェクトに入れること。と説明している
ユニットテストにおける仕組みを理解をする上でこの本では説明されているが、DI自体は思想であり設計技法なので、デザインパターンといえる
なのでシステムのコードにDIを適用するともいえる
DI化されているとは、ユニットテストができるようなソースの状態といえる
DI化したとは、具象としてだけ存在していたクラスを抽象クラス化して外部から固有情報を渡せるようにした。といえる
ユニットテストにおけるDIとは
「監視、操作したいオブジェクトをモック化し、テスト対象のオブジェクトのコンストラクタを通じて送り込むこと」
このテストオブジェクトの方をモックと呼ぶ
監視・操作とは、テスト対象のシステムに応じたテストデータを作成するためにテストオブジェクトを生成するので、開発を進めていく上で操作しつつ、あるべき姿のテストオブジェクトかを監視し続ける必要がある。ということ
DIによって可能になる、テストにおいて重要なこと
- モックをテスト対象のオブジェクトの外からから操作できる。 (つまりユニットテストができる)
- ユニットテストの実行時に、モックに対して行われた操作をトラッキングし検証できる。(つまりデバッグできる)
テストデータ(オブジェクト)もシステムの1つと考えること
例えば、ある特定の地域をシュミレートするシステムがあったとして、その設定値として「ハワイ」、「晴れ」、「-10℃」などとすることができる
これらの地名、天気、温度などは組み合わせを変えることによってシステムの様々な仕様を検証できるのでテストオブジェクトもシステムと一体のものと考えられる重要なもの。ということ
エクスペクテショーンの設定とは
ユニットテストの実装において、モックオブジェクトを生成し、テスト対象オブジェクトにモックオブジェクトを渡してコンストラクタすることをエクスペクテショーンの設定という
難しく聞こえたが、実行結果が得られるメソッドを叩くのに必要な事前処理
つまりDI化によってユニットテストできる状態になり、ユニットテストはエクスペクテーションの設定によって最後実行結果と期待する値を比較し、テストを成立させることができる
書籍情報
Jonathan Rasmusson, 玉川 紘子 初めての自動テスト
https://amzn.to/2S7dbCj
雑感
この本を読んでいた矢先、DDDアーキテクチャを用いた現場にてDIを使ったことがあるかと問われ、「ユニットテストのこと? (なんでそんな抽象的なものに対して使うという表現するんだろう)」と思ったがある程度整理ついた気がした。フレームワークを使ってない事とも結びつき、デザインパターンを適用した事あるという意味だったと理解した。
フレームワークを使っているとあらかじめほぼ担保されている部分で、実装者の責務が比較的小さい部分をDDDの場合はある程度ベースから考えて行く必要があるという性質も感じた。
技術者の知的好奇心を刺激するという意味においてDDDは良いと思った。
プロダクトのグロース、開発効率、ビジネス的な観点からどうかというのはまた気になる。