読者です 読者をやめる 読者になる 読者になる

DIと、時々テスト

「DI嫌い」っていう話をよく聞くと、「IFと実装の対応が分かりにくい」みたいな理由は多いけど(・ω・)


それって、なにも考えずに「全ての要素はIFと実装はセットで用意すべき」だと思い込んでるアホな設計の話とか、DIパターン及びコンテナの話を混同しているだけだったりすることも(・ω・)?
なんでもIFと実装分離パターンに対するイライラを、DIやデータアクセスパターンのせいにするケースを未だに見るけど、それってDIやパターンの問題じゃ無いと思うのよ。
自分んらの所の、設計と(使っている)実装の問題にすぎねーからな、なんつったりもして(・∀・;)


あと、未だにDIとAOPを混同しているケースがあるのはどうしたもんかしらん。
IFと実装をセットで用意するものだと思い込んでいるケースもそうだけど、変な理解をしているケースの方がタチが悪い(´・ω・`)
DIなんか使うから問題なんだというのは、Dependency Injectionパターンと、AOPの話と、コンポーネント管理(アプリケーション固有の設計方針)の話を混同した、割とありがちな話じゃないかと思うの(・ω・)


コンポーネント管理としてのDIは必要、AOPが出てくるのは拡張ポイントが不十分な証拠、もしくは対象の前後に処理を挟みたいものはRAII的な手法でスコープを使ってやれ、
…っという考えは前から変わっていないんだけど、最近はなにか変ってきているところもあるのかしら(・ω・)?


DIを使う目的として、テストを引き合いに出されるのはどうも違和感があるノ(・ω・)
テスタビリティの話は、コンポーネントのモジュラリティの話で、DIを使うかはどうでも良いし。
単に、コンポーネントの組み立てに使うためにDIを使う、っというだけじゃイカん崎(・ω・)?


テストのために、ControllerやServiceみたいなものまでIFと実装を分離するとか、単に何も考えていない証拠だと思うのよ。
設計的に、本来プロバイダーモデルを用いるべき所だけモックに差し替えられれば、テストで困ることもない、っとも前から思っているのだけど(・ω・)


テストというと、Webだけやっていて、ユニットテストがピンと来ないというのは分らんでもないけど(・ω・)
単純に言ってしまえば、「ステート」も無ければ「ロジック」も無いからで(・ω・)
対象がステートやロジックを持っていないとユニットテストの価値は感じにくいわけで、ユニットテストのお勉強で自販機なんかがよく例題に出されるのも、その観点から適当な題材ということだし(・ω・)
シンプルなWebアプリの場合、バウンダリから永続化までが単純な呼び出しになるので、ルート、コントローラー、データストアとかのテストにたいした意味を見いだせないというのは、まあそうかなと。


Webのアプリケーション層においてその価値を感じやすいのは、データストアのモデルからプレゼンテーション用に構造変換するプレゼンテーションモデルの所や、パーシステントには依存しないコアドメインのロジックあたりかしらね(・∀・)?


後は、ユニットテストという範疇からは外れるけれど、データストア自体をステートとして、Mockをとかは使わずアプリは本物でVMとかを使って、ユースケースをテストとして書いてデータストアの中身を事後検証するとかね(`・ω・´)
これはCIで都度走らせるにはコストが高くなるので、Dailyでとか、コード/コンポーネントの検証というよりリリース状態を保てているかの検証になりますが(・ω・)
Webアプリの場合、ユニットというより、回帰テストという点を全面的に打ち出して、ユースケースの単位で、モックの代わりにVMを使い、ステートはDBとかにパーシストされたものを検証、っという方が良いと思うのよ(・∀・)
テスト内の処理の呼び口は、サービスファサードで、コストメリットがあると思えばコントローラー層に対する疑似リクエストからやっても良いけど。
UIレベルのテスト?、コストメリットがあると思えばね…。UIを含めたテストは変更コストが高くなるし(´・ω・`)


そもそも、モックの多いテストというものについては、そのテストに意味があるのかという以前に、そもそも構成が正しいのかという疑念があり(・ω・)


テストの話というか、責務の設計とかの話については、Webアプリを例にしても、たいした議論にならんだろうと思う面もあったりするけれど(・ω・;)
Webアプリの場合、アーキテクチャを単純化された公式に当てはめちゃっても、ぶっちゃけ困らないことも多いので、それで何か語るって言ってもな〜、つって(・∀・;)
テストの価値とか、責務の設計、機能の分割というよりオブジェクト間の契約について議論するのであれば、Web以外のドメインを例にしないと価値が伝わりずらいよね、っと(・ω・)


まあ、Webのアーキテクチャは単純だとかなんとか言うと、ちょっと反感を覚えないでもないけど。
しいて言うなら、注力するポイントはそこではないというべきかしら(・ω・)?
じゃあ、注力するポイントはどこなのかと言うと、あんまり良い回答じゃない気もするけど、ビュジュアリゼーションとか、スケーラビリティ、モニタリングとか(・ω・)?


まあ、テストを含め、責務の設計とか語るのは、他のドメインのソフトウエア開発を色々やってからでも良いと思うのよ(・ω・)
組み込み(といっても低レイヤの意味ではなく、ステートを持ったものの意味、自販機もこの範疇)とか、人のメンタルモデルのシミュレーションをして結果を得るようなアプリケーションだとか。


それまで、ステートと複雑なロジックの組み合わせによる決済系の処理をやっていた若者が、Webアプリケーションをやりはじめて、「Webアプリケーションって簡単ですね」っと言った言葉を、おじさん、忘れられなくて(・∀・;)


閑話休題、話をDIに戻して。


あと、いまいちよくわかっていないんだけど、.NETだからDI使っていないという話なんだけど、そういう人って違うレイヤのコンポーネントなりなんなりの参照をどう解決しているのかしら(・ω・)?
単にPoor Man'sとか自前Service Locator、あるいはstaticおじさん(・ω・;)なの?

Dependency Injection in .NET

Dependency Injection in .NET