モックフレームワークとかテスト用のDIツールに関する私見
-
- いいね！0
非実在naka aki
@naka_aki_spl
そういやテスト用の差し替えのためにDIがイイってな話を聞いたような気がするんだけど、実際使ってるかんじをあまり受けないような気もする。 もしかしてOOPの継承が最後の武器（滅多に使うな）扱いされちゃってるのと似てるのか？＞テストとか用の差し替えにDI活用
2013-09-23 21:46:49
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@naka_aki_spl DIフレームワークの話だとすると、その設定をテストメソッド単位で変更できないから使いにくいって話で、それゆえにモックフレームワークが台頭しているのだと思う。メタプログラミングやりやすい言語だとフレームワーク使わない事もある [休眠＊´×｀＊エンジニア]
2013-09-23 21:58:01
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
OOのテストコードでテストメソッド名をうまくかけないエンジニアはユースケース設計とか分析ができないクズだと思っている。っていう言葉を残しておこう。 [休眠＊´×｀＊エンジニア]
2013-09-23 21:59:46
Shin Tanimoto / CERO-METAL
@cero_t
@kyon_mm @naka_aki_spl やや、それは違うと思います。モックフレームワークが台頭しているのは、テスト対象のコードが十分に構造化されたり分割されていないせいだと思うんですよ。逆に僕は、自分の開発プロジェクトでは、モックフレームワーク禁止してますよ。
2013-09-23 22:02:13
Shin Tanimoto / CERO-METAL
@cero_t
@kyon_mm （DIコンテナを入れれば、確実にテスタビリティが向上するので、DIコンテナを入れたことでテストしにくくなって、モックフレームワークが台頭してきた、ってことはないと思います、という意味です）
2013-09-23 22:04:27
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@cero_t @naka_aki_spl そういう捉え方もあるのはとても理解できます。どっちがマジョリティなのかは僕にはわからないです＞＜ 使いたい場所で使うモックとあまりメリットが大きくない場所でモックでずいぶんと話が変わりますからねぇ。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:05:44
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@cero_t あー。たぶん意図が違います。僕が言っているのはテスト用のDIフレームワークの話ですね。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:06:12
非実在naka aki
@naka_aki_spl
@cero_t @kyon_mm もしかしてあれかな： 「デバッガっていまいちキモイよね」って感覚と似たものがモックにも有る、 ってかんじですかね？
2013-09-23 22:36:50
Shin Tanimoto / CERO-METAL
@cero_t
@naka_aki_spl @kyon_mm いや、キモいだけなら良いんですけど、使い方をミスって「意図した場所を通ってなかった」「全然違うテストをしていた」「テストしなくて良いテストをしていた」「テストコードをテストしていた」が多すぎたんで、使わない方に倒しました。
2013-09-23 22:38:57
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
DIを使う事でテストコードのために差し替えを行う事はできるけど、デプロイしたら変更されないコンテキストを想定されたDIフレームワークだったら、テストコードで表現したい差し替えを実装できなくって、その小回り良さのためにモックフレームワークが存在する。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:10:41
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
一方でプロダクト設計がにっちもさっちもいかなくなって、どうにかテストするために使われているモックという場面も存在するし、それはテスト手法でもいくつかでているものだったりする。どうやってブラックボックステストに立ち向かうかみたいな。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:13:16
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
モックフレームワークの正しい使い方の１つはGOOSにあるような、オブジェクトネットワークを認識した上でモックフレームワークを使う事によって、テスト対象とテスト対象外を宣言できるという強大なメリットを得る事だと思う。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:14:49
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
モック使わずにテスト対象とテスト対象外を上手に宣言するにはかなり心を込めてテストコードを設計する必要がある。そしてそれはあまりプログラマーは好きじゃないと思う。たぶん実際にどういった仕事をしているか次第だけど。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:16:21
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
TDDの自殺のブログや発表で「モックを使う事にメリットがないように見える」って意見をもらうけど、概ねあってるけど、手軽に「テスト対象外を宣言する」にはとても有効だと思う。でも、テスト対象外の再利用性に気を使わない方向に走りやすいのでやっぱり嫌です。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:19:29
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
仮にテストコード用のDIがあったらと思うけど、Groovyなんかだと「Categoryをこうやって使えばいい感じになるよ」ってくらいで十分だったりするので、そういった方向でいいと思っているが、.NETだとどうなるのか。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:21:40
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
Given, When, ThenもWho, What, Whyもユースケースをテンプレ化するなにかなわけで、Kent, Beckの「ユーザーの立場で書くんだ！」では広まらなかったものを表現した訳だが、これは命名方法じゃなくて、説明方法だからなー。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:37:37
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
ユースケース名とかシナリオ名とかを考えるのとても大切だと僕は思う。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:38:33
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
個人的には、ユースケース名を書いているのかテスト観点名を書いているのかわからなくなるときがあるので、まだよくわかっていないんだろうなって気がしている。 [休眠＊´×｀＊エンジニア]
2013-09-23 22:52:26