ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと ｜ Developers.IO

ドキュメントベースの単体テスト ソフトウェア開発では、テストケースをExcel等で管理し、テストをテストフェイズで実施する方式（以下、ドキュメントベースの単体テスト）が行われてきました。 ドキュメントベースの単体テストでは、テストフェーズが明確に切られています。テストフェーズでは、テスト担当者がテストを実施し、結果をドキュメントに記録します。必要に応じてエビデンスも残すでしょう。もし、テストが失敗したならば、不具合管理票（バグ票）を起票します。そして、不具合の原因を分析し、仕様書やソースコードを修正します。不具合が修正されたならば、もう一度テストを実行し、不具合がなくなるまでこのサイクルを繰り返し、品質を高めていきます。 このようなドキュメントベースの単体テストは、機能や画面を対象としています。そして、ほとんどの場合は品質保証を目的としています。テスト件数や不具合件数、不具合の発生原因や修

[bufferings]

ネジが正しく作られていることのテストと、製品が正しく作られていることのテストってイメージ。前者はxUnitで、後者もできるとこまでxUnitであとはドキュメントかな。頭の中で混ぜると危険。

[hiyang]

読むべき人に届くと良いんだけどな～。

[masaru_b_cl]

ドキュメントベース、xUnit双方が苦手な部分を補い合うのが理想ですよね

[t-wada]

“もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません”

[motsuni2]

単体テストとxUnitの違い

[gorimaru7]

もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません。xUnitは小さなプログラムを動作確認する

[ismage]

via Developers.IO http://dev.classmethod.jp