- kimukou2628
- 2057
- 0
- 0
- 0
@tosikawa 世の中の女性は神速たんにきゅんきゅんしてしまう。というお話です!僕が神速たんにきゅんきゅんするのは摂理です!(あ
2011-03-21 11:03:071. ユースケースと画面モックを作成 2.ユースケースをグループ化 3.グループ毎に低レベルレイヤーから実装(ユースケース/レイヤーで1チケット) という流れがベストかなー
2011-03-21 11:06:09.@shuji_w6e @a_hisame テスト戦略は何を中心にテストを組み立てるかという方針です。流れとしては、テスト戦略、テスト分析、テスト計画、テスト設計となります。なのでさっきのツイートはちょっと不適切ですね。言いたかったのはテスト設計までの流れとTDDについてです。
2011-03-21 11:12:38@kyon_mm だとすると、TDDは開発手法に近いからテスト戦略とは切り離すのが理想。ただ、ステークホルダを納得させるためにやや強引に関連づける事が現実だと思う。
2011-03-21 11:15:22@kyon_mm 自分はTDDでは「まずできる事から」テストを作っていって、GREENを確認しながらテストのリファクタリングを進めて行きますね。あと、TDDのテストは設計対象の使い方を考える事も強いメリットであると考えてるので「どの様に使いたいか」を考えてテストを書いてます。
2011-03-21 11:15:27テスト戦略、テスト分析、テスト計画、テスト設計、テスト実装、テスト実行、テスト報告。。。が一連の流れだと思う。それぞれかぶっていたりする部分があるとは思うけど。
2011-03-21 11:15:31@kyon_mm その辺のはなしはとちぎテストの会議なので色々議論されたりしていて、まだ定説はないというか、これから色々まとまってくるかんじだとおもいますよ。
2011-03-21 11:15:54@shuji_w6e そこが悩みどころというか、さっきのお話につながって、ユースケースはやっぱり最初にあると思うんです。ある程度のストーリー。そこがテスト設計に関わってきたりするんじゃないかと。(どうやって観測するのかとか)
2011-03-21 11:17:52@kyon_mm TDDだと結構真逆かも。テスト実装>実行>(自動的な報告)>(場合によっては網羅性の追加)、テストのリファクタリングによる「開発者のための」テストを対象にするので。コード保証のためのテストは、被ってる部分もあると思いますが、自分は(今の所)別物と考えてます。
2011-03-21 11:18:06@a_hisame まさしくそれがTDDだと思います。自分でドッグフーディングすることで設計の質を高めて行く。
2011-03-21 11:18:55@tosikawa やっぱりそうなんですねー。去年の栃木テストにすっごくすっごくすっごく行きたかったですw
2011-03-21 11:19:24.@kyon_mm ユースケースがテストに関連付くのは自然ですね、システムテストや結合テストという形で。テスト駆動を適用するならば、ユースケース記述レベルからシステムテスト項目をブレイクダウンして、レビューを通してから実装となるのでしょうが、コストとのトレードオフかも。
2011-03-21 11:20:50@a_hisame たしかに。ただTDDって実装したいユースケースはありますよね?そこの兼ね合いかと。テスト戦略からテスト設計までは「どうやってテストすることが最もいいのか」を考える段階です。そこがあってTDDに流れて行くのが自然かなーって思ったり。よくわかってないですがw
2011-03-21 11:21:57