4

私はCodeCompleteを読んでいます。その本の中で、スティーブ・マコネルは「開発者のテストは「クリーンなテスト」になる傾向がある」と警告しています。開発者は、コードが壊れているすべての方法をテストする（ダーティテスト）のではなく、コードが機能するかどうかをテストする（クリーンテスト）傾向があります。」

コードが壊れている方法のテストを作成するにはどうすればよいですか？つまり、不正な入力のテストを記述して、正しくブロックされていることを確認できます。でもそれとは別に、どんなことを考えたらいいのでしょうか？ここでMcConnellはどういう意味ですか？私は基本的な単体テストに慣れていますが、それをマスターしようとしています。

4

3 に答える 3

6

私はあなたがここで正しい道を進んでいると思います。コードが機能することを証明するためのテストでは、プログラムが通常の状態で、意味のある、意味のある、期待される入力を持つメソッドを呼び出します。コードを解読するためのテストでは、そのコードについて「箱から出して」考えようとします。したがって、意味のない、または予期しない入力を使用します。

しかし、私見で重要なのは、2つの思考プロセスが非常に異なることを理解することです。開発者がTDD方式でコードを作成する場合、開発者はコードに実装するさまざまな機能に焦点を当てる傾向があり、これとその機能またはユースケースが指定どおりに機能することを証明するテストを行います。この方法で作成されたテストは、McConnellが「クリーンテスト」と呼んでいるものです。

コードの一部がどのように壊れるかを考えるには、非常に異なる思考プロセスと異なる経験も必要です。メソッドとAPIを別の角度から見る必要があります。たとえば、これらのメソッドとパラメーターの目的について知っていることを一時的に脇に置き、それらを使用して技術的に可能なことだけに焦点を当てる必要があります。また、このメソッドが正しく機能するために必要なすべての（多くの場合暗黙の）前提条件または依存関係について考えること。DBから読み取った構成パラメーターに依存しますか？ファイルシステムに書き込みますか？事前に適切に初期化されていることを期待して、別のコンポーネントを呼び出しますか？大量のメモリを使用していますか？GUIにメッセージを表示しますか？...そして、これらの1つ以上が成り立たない場合はどうなりますか？

これはすべて重要な質問につながります：あなたのメソッドはそのような汚いケースをどのように処理する必要がありますか？クラッシュする必要がありますか？例外をスローしますか？できる限り最善を尽くしますか？エラーコードを返しますか？エラーレポートをログに記録しますか？...これらの小さな決定または大きな決定はすべて、メソッドまたはAPIのコントラクトを正しく一貫して定義するために実際には非常に重要です。

ケント・ベックは、同じ意味で「開発者の帽子」と「テスターの帽子」の着用を切り替えることについて話します。このように視点と思考プロセスを流暢に切り替えるには、実践と経験が必要です。

于 2012-06-28T15:53:07.410 に答える
1

作成者がクリーンテストで意味する可能性が最も高いのは、メソッド実行のハッピーパスのみを検証するテストです。

ハッピーパスのテストは通常​​最も簡単で、人々はそれが機能するので、テストを書くという彼らの仕事は終わったと思う傾向があるかもしれません。これはめったにありません。検討：

public void SaveLog(string entry)
{
    var outputFile = this.outputFileProvider.GetLogFile();
    var isValid = this.logValidator.IsValid(outputFile);
    if (isValid)
    {
        this.logWriter.Write(outputFile, entry);
    }
}

ハッピーパステストは、すべての依存関係（ outputFileProvider、、）が機能し、書き込みが実際に行われていることを前提としています。ただし、途中で何かが壊れる可能性が高いため、これらのパスもテストする必要があります。好き：logValidatorlogWriter

  • outputFileProvider出力ファイルの取得に失敗します
  • outputFile無効であることが判明
  • logValidator独自の例外で失敗する
  • logWriter書き込めない

ほんの数例を挙げると！ユニットテストには、単にハッピーパスをチェックするだけではありませんが、残念ながら、これはよくあることです。

于 2012-06-28T15:56:41.703 に答える
1

TestObsessedのElisabethHendricksonは、あらゆる種類のテストアプローチをリストしたテストヒューリスティックチートシートを持っています。このドキュメントは大まかにテストに関するものですが、「データ型攻撃」というセクションには、「不幸な道」の単体テストで確認できる具体的な例がたくさんあります。

たとえば、パスとファイルをテストする方法についての彼女のアイデアは次のとおりです。

長い名前（> 255文字）
名前の特殊文字（スペース*？/ \ | <>、。（）[] {};：'“！@＃$％^＆）
存在しない
すでに存在する
スペースなし
最小スペース
書き込み-保護された
使用不可
ロック
オンリモートマシン
が破損しています

于 2012-06-28T18:17:18.367 に答える