①日時依存の対策方法 ⇒ アプリケーション内で日時をコントロール機構を用意(現在日時でテストしない)。次点で、テストコードで動的にデータを作る。ただ限界として、前月分集計とかテストしたいみたいな所はやり難い。最悪、運用回避! #bpstudy
2014-10-31 20:16:16#bpstudy 日時依存のてすと。アプリケーション側で日付をコントロールする機構がないとそもそもテストできないこともある(特に金融系)。次点でテストコードで動的にフィクスチャを生成することで吸収。
2014-10-31 20:16:29#bpstudy テストというとわりとUnitTestを想定してしまうんだけど、ここで言うテストはどのレベルになるのかな。 もうちょっと網羅的な内容を想定してる気がするけど、ある程度内部に手を入れる前提な感じもするので微妙にイメージがつかない
2014-10-31 20:18:13#bpstudy テストケース内で使うデータは各テストケースで独立に準備する。如何しても難しい場合は各ケースで依存関係を明記する。
2014-10-31 20:18:15①順序・データ依存の対策方法 ⇒ テストケース内で使うデータは各テストケースで独立に準備する。 #bpstudy
2014-10-31 20:19:07#bpstudy テストケースがデータまで責任を持つ、はかなり大事 一方、テストが予定調和になっちゃう感とかあるけどその辺どうなんだろう?
2014-10-31 20:19:31②変更に弱いテスト。文言・レイアウト変更時の保守工数が大きい。テストスクリプトが構造化されていないパターン。自動記録とか使ったらなりがち。 #bpstudy
2014-10-31 20:20:29#bpstudy 変更に弱いテスト。テストスクリプトが的確に構造化されていないと、変更時の影響範囲が広くなってしまう。アホなツールで自動記録してるとありがち。→対策。PageObjectパターンなどを使ってテストを構造化する。画面の作りに依存するものとしないものを分けちゃう。
2014-10-31 20:21:57#bpstudy view層とコントロール層を分けるって感じですよね ナウいフレームワーク使ってたらテンプレとコントロール分離してるしこのパターンはかなり有効←page objectパターン
2014-10-31 20:23:46キーワード駆動で非プログラマを巻き込んで構造化。……つってと実はテストケースを書ける非プログラマのビジネスエキスパートの手が取れない事が多い #bpstudy
2014-10-31 20:25:23#bpstudy ユビキタス言語に近いものだとは思うけど、DDDとは違うような?(「ドメイン駆動設計」で意図してる範囲ではない気がする)
2014-10-31 20:25:45変更に弱いテストの対策方法 ⇒ PageObjectパターンなどを使ってテストを構造化。さらに、キーワード駆動を使って構造化するのにトライしているとのこと。キーワードを自然言語で定義、それをテストケースに組込むような方式。プログラマと非プログラマを役割分担できる。#bpstudy
2014-10-31 20:25:56