ユニットテストの方法論 - レベルエンター山本大のブログ
ひがさんの意見！さすが！目から鱗の提案だ！ ひがやすを blog ■極力ユニットテストを書かずに品質を確保する方法 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 http://d.hatena.n
自動テストとデイリービルドの組み合わせは最強！ - レベルエンター山本大のブログ
自動テストとデイリービルドを組み合わせることの超絶な威力を感じてる。 しかし、開発の中に上手く自動テストを組み込めていないプロジェクトは多い。 デイリーでテストコードを流しておくと、修正による副作用を最低でも1日以内に発見することができるようになる。 影響を恐れずに修正ができるため、大胆なリファクタリングも可能だし、仕様変更にとても強くなる。 結合テスト以降は、特に強力で自分の作っていないプログラムでの修正や操作が自分のプログラムに影響を与えることがある。 それを知らせてくれる仕組みがあるということが安心感は絶大だ。 そもそもテストコードを作ると、コーディング時やデバッグ時に起動ポイントとして使える。 Web画面を起動しなくていいぶん楽にコーディング・デバッグできる。 「じゃあ、Web画面からの入力テストはどうするんだ？」とか 私も昔は思っていたけど、画面入力のテストなんかは無理に自動化し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
