[cubby-dev:22] Re: テストケース周りの整備

2008年 11月 27日 (木) 04:38:32 JST

染田です。

> ざっくりとですが、みてみましたー。

ありがとうございますー。

>> (1) MockRequest/MockResponse の生成について
> 中略
> ユーザ任せのほうに一票。
> MockHttp～ も EasyMock も、他の選択肢があるので、Cubby が提供しないほう
> がいいんじゃないかと思います。
> Cubby 本体のテストのため、ならアリと思います。

了解ですー。他の方からも特に異論なければ近々消しておきます。
Cubby 本体の方のテストでは、ある程度共通点見いだせたら、簡単に
EasyMock の Request/Response の簡単な組み立て出来たら楽かも、
ですね。

> とりあえずコミットしてしまってください。

コミットしました。cubby-guice の方に、MockServletModule と
この子が数点 guice-servlet へ依存しているため、pom.xml を変更しました。

> GuiceFilter でやっている処理って、GuiceFilter#getRequest や getResponse
> が問題？

ですです。
ServletModule 側から、直接この GuiceFilter の static メソッドを呼んでる
部分です。
後は、ServletScopes#REQUEST/SESSION なんかも、この GuiceFilter
の static メソッドを呼んでました。

最初、doFilter を直接呼ぶか、と思っていたのですが、finally で
context を戻してしまっているため、外側からだとコントロールしにくくて。。。
ということで、Mock を当てるのがよいかな、と思った次第です。

guice-examples の方にも、上記の MockServletModule を利用する
アクションのテストの方追加しておきました。
# HttpServletRequest に対する expect の整理はまだ、なのですが。。

# 近々に、小さい規模の Web アプリを新たにたてる事になりそうです。
# cubby 2.x + s2 でいくか、今検討してるところです。

染田

2008/11/27 BABA,Yasuyuki <[E-MAIL ADDRESS DELETED]>:
> 馬場です。
>
> ざっくりとですが、みてみましたー。
>
>
>> -> PathProcessor という名前があんまり、かもです。すみません。。。良い
> のが思いつかず。。。
> RequestProcessor とか・・・？
> うーん。
>
>
>> (1) MockRequest/MockResponse の生成について
> 中略
>> # モックの Request とか Response の生成は、ユーザ任せでもいんでない？
>> # というスタンスもあるのかもしれません。
>>
> ユーザ任せのほうに一票。
> MockHttp～ も EasyMock も、他の選択肢があるので、Cubby が提供しないほう
> がいいんじゃないかと思います。
> Cubby 本体のテストのため、ならアリと思います。
>
>
>> (2) cubby-guice 側へのテストケースパッケージ
>>
>> guice のテストケースを書いていて気づいたのですが、ServletModule を
>> すげかえないと、GuiceFilter でやっている処理をエミュレート出来ず、
>> こちらのモックを cubby-guice においてしまおうかな、と思っています。
>>
>> 問題なければ cubby-guice 側にもテストケース用の unit パッケージを
>> 置いて、モックを作ってしまおうと思ってます。
>> org.seasar.cubby.plugins.guice.unit です。
> とりあえずコミットしてしまってください。
> GuiceFilter でやっている処理って、GuiceFilter#getRequest や getResponse
> が問題？
>
>
> Takashi SOMEDA さんは書きました:
>> 染田です。
>>
>> 遅ればせながら、合宿お疲れ様でした。
>> 色々と勉強させて頂きました。
>>
>> さて、テストケース周りの整理の方少しずつ進めており、
>> 一部コミットしましたので、ご連絡しておきます。
>>
>> 触った所でいいますと、
>>
>> (1) CubbyFilter 内での処理を PathProcessorImpl へ delegate 。(馬場さんと合宿でお話した件)
>> -> PathProcessor を新たに追加し、hasPathInfo メソッドと process メソッドへ
>>     Filter で行った処理を委譲
>> -> PathProcessor という名前があんまり、かもです。すみません。。。良いのが思いつかず。。。
>>
>> (2) org.seasar.cubby.unit 以下に諸々のクラスを追加
>> -> 各種 cubby-s2/cubby-guice の方で利用出来るような、
>>     CubbyRunner/CubbyAssert へ整理し直しました。
>>
>> 既存のテストケースは全て通っている事を確認してコミットしました。
>>
>> (1) については、パッケージを router.impl 内への設置に伴い、CubbyRequestWrapper を
>> こちらに移動しておきました。
>> テストケースも移行したので、多分動作は大丈夫だと思います。
>> # guice-examples の稼働も確認してます
>>
>> 手元では、guice-examples で、HelloAction のテストケースも動くように
>> なっているのですが、こちらはもう少し整理してからコミットしようと
>> 思っています。
>>
>> ここで、二つほどご相談があります。
>>
>> (1) MockRequest/MockResponse の生成について
>>
>> あれば楽かもしれない、と思い、org.seasar.cubby.unit 以下に
>> S2 の MockHttp* を移行してあります。
>> 実装もほぼほぼ S2 のままなのですが、内部実装を EasyMock を
>> 利用するように変えて、
>>
>>   HttpServletRequest req =
>> CubbyMock.createRequest().param("a2","hoge").setAttribute("aaa","bbb").header("referer","fuga").execute();
>>
>> みたいな感じにする方が手軽かも、と思ったりもしています。
>> 実際 S2 のテストケースを実行する時も、ほとんどパラメータと
>> アトリビュートの設定が中心ですし。。
>> # 最後の execute で replay するイメージ
>>
>> Cubby 本体のテストにも使えるかな、などとも思っているのですが、
>> この辺り何かご意見ありますでしょうか。
>>
>> # モックの Request とか Response の生成は、ユーザ任せでもいんでない？
>> # というスタンスもあるのかもしれません。
>>
>> (2) cubby-guice 側へのテストケースパッケージ
>>
>> guice のテストケースを書いていて気づいたのですが、ServletModule を
>> すげかえないと、GuiceFilter でやっている処理をエミュレート出来ず、
>> こちらのモックを cubby-guice においてしまおうかな、と思っています。
>>
>> 問題なければ cubby-guice 側にもテストケース用の unit パッケージを
>> 置いて、モックを作ってしまおうと思ってます。
>> org.seasar.cubby.plugins.guice.unit です。
>>
>> 簡単ですが、お知らせまで。
>>
>> 染田
>
>
> --
> BABA,Yasuyuki
> [E-MAIL ADDRESS DELETED]
> _______________________________________________
> cubby-dev mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/cubby-dev
>


-- 
======================================
株式会社チョイスタジオ
取締役 CTO 染田貴志
mail: [E-MAIL ADDRESS DELETED]
www: http://www.choistudio.jp/

〒604-0044
京都府京都市中京区下古城町376-305
TEL: 050-3597-1906
======================================