私の質問は、ある種の単体テストは価値があると人々がすでに信じており、実際にそれらを現在のプロジェクトに書き込んでいることを前提としています。また、コードの一部の単体テストは、些細な機能をテストしているため、書く価値がないと仮定しましょう。例としては、ゲッター/セッター、および/またはコンパイラー/インタープリターがすぐにキャッチするものがあります。反対の仮定は、「興味深い」コードはテストする価値があるということです。
9 に答える
8
コードの領域のカバレッジレベルは、変更の可能性とそれに依存する機能の量の組み合わせに正比例する必要があります。
たとえば、基本制御クラスのコアには、かなり複雑な解析ロジックがあります。影響を受けないシステムからの入力を処理する必要があるため（変更の可能性が高い）、すべてのUIコントロールが安定していることに依存しているため、絶対的な小便を単体テストします。ベースのわずかな微調整は、継承と依存のレイヤーを介して波及し、拡大します。
于 2009-02-18T05:10:27.190 に答える
2
レイヤー間で渡されるデータを検証する単体テストは、多くの場合、最大の価値を追加します
UI<---->ビジネス<--->データ
于 2009-02-18T05:10:59.823 に答える
0
多くの場所で再利用できるテスト。私の現在のプロジェクトの例：
- 構成ファイルの構文チェック
- RTFテンプレートで参照されているモデルプロパティが実際にモデルクラスに存在することを確認します（人々はクラスを変更し、通常はテンプレートの調整を忘れます）
- 見落とされがちなスタイルガイドルールの確認（各UIマスクにはタイトルバーのテキストが必要であり、各ボタンには一意のニーモニックが必要です）。
単体テストに懐疑的なプログラマーでさえ、最小限の作業で単体テストを使用できるため、これらを気に入っています。場合によっては、独自の単体テストを作成することになります。
于 2009-07-05T16:31:32.263 に答える
0
私自身の質問に答えるために、テストする価値のあるモジュールを次に示します。
a）ビジネスルールのいずれか。私の現在のアプリケーションでは、ビジネスルールはビジネスオブジェクトから外部化されています。
b）ビジネスオブジェクトの仮想属性のいずれか。多くの場合、これらの仮想属性にはアルゴリズムが含まれています。
c）消費された特定の入力に対して期待される生成された出力を示すことができる主要なコンポーネント。多くの場合、これは統合テストに流れ込みます。
d）開発プロセスでは、ユニットテストで新機能とバグ修正をチェックインする必要があります。バグ修正については、バグの原因を正確に複製し、コード修正がチェックインされると単体テストに合格できることを示します。
e）あるデータ表現タイプからPOJO-XMLなどの別のデータ表現タイプに変換する変換レイヤーのいずれか
于 2009-02-18T05:11:25.017 に答える
0
TDD はコードの記述を高速化するのに役立ちます。そのため、TDD を高速化する場合にのみ、より多くのビジネス価値が提供されます。;)
于 2009-02-18T17:56:55.257 に答える
0
SO Podcast 41で議論- この部分は現時点ではトランスクリプトに含まれていません。ブログの回答には、単体テスト カバレッジの値に関する詳細な説明が含まれています。
- Joel は、過剰な TDD (たとえば、テスト カバレッジが 90% から 100% になる) が、ソフトウェア製品に利益をもたらす可能性のある他の活動 (ユーザビリティの向上やユーザーが求めている追加機能など) から時間を奪うことを心配しています。
- 単体テストは、「独自のドッグフードを食べる」形式として、またシステムの動作を文書化するために非常に役立ちます。テストの実際の結果を完全に無視したとしても、それらはドキュメントとして価値があり、コードベースに関する新鮮な外部の視点を提供します。
- Joel は、UI (Web または実行可能ファイル) のテストと UI の背後にあるコードのテストの難しさを指摘しています。これを行う古典的な方法は、おそらく The Art of UNIX Programming に記載されていると思われます。そこでは、テキストを取り込んで吐き出すコマンドライン アプリから始めます。GUI は、コマンドライン アプリの上に貼り付けるレイヤーにすぎません。これにより、完全なテスト容易性が実現しますが、長い目で見れば、それほど優れたアプリとは言えません。どちらがより重要ですか?
于 2009-02-18T06:46:39.360 に答える