単体テストに合格するための最小限のコードを書く-不正行為なし！

TDDを実行して単体テストを作成する場合、テストする「実装」コードの最初の反復を作成するときに、「チート」という衝動にどのように抵抗しますか。

例：
数値の階乗を計算する必要があります。次のような単体テスト（MSTestを使用）から始めます。

[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}

このコードを実行すると、CalculateFactorialメソッドが存在しないため失敗します。そこで、テスト対象のメソッドを実装するためのコードの最初の反復を記述し、テストに合格するために必要な最小限の コードを記述します。

実は、私は次のように書き続けたいと思っています。

public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}

これは、技術的には、それで正しいです、本当に最低限のコードをするために必要とされている特定のテストパス作るそれは本当にさえいないので、それは明確に「チート」ですが、（緑行く）を試みる階乗を計算する機能を実行します。もちろん、今では、リファクタリングの部分は、実装の真のリファクタリングではなく、「正しい機能の記述」の演習になります。明らかに、異なるパラメーターで追加のテストを追加すると失敗し、リファクタリングが強制されますが、その1つのテストから開始する必要があります。

だから、私の質問は、「テストに合格するための最小限のコードを書く」ことと、機能を維持しつつ、実際に達成しようとしていることの精神とのバランスをどのように得るかということです。

それは完全に合法です。赤、緑、リファクタリング。

最初のテストに合格しました。

新しい入力を使用して、2番目のテストを追加します。

すぐに緑色になり、if-elseを追加できます。これは正常に機能します。合格しましたが、まだ完了していません。

Red、Green、Refactorの3番目の部分が最も重要です。 重複を削除するためのリファクタリング。これで、コードに重複ができます。整数を返す2つのステートメント。 そして、その重複を取り除く唯一の方法は、関数を正しくコーディングすることです。

最初は正しく書かないでくださいと言っているのではありません。私はあなたがそうしないなら、それは不正行為ではないと言っています。

明らかに、最終目標の理解と、その目標を達成するアルゴリズムの達成が必要です。

TDDは設計の魔法の弾丸ではありません。コードを使用して問題を解決する方法をまだ知っている必要があり、テストパスを行うためにコードの数行よりも高いレベルでそれを行う方法を知っている必要があります。

TDDが良いデザインを促進するので、TDDのアイデアが好きです。テスト可能なようにコードを記述する方法を考えるようになります。一般的に、この哲学はコードを全体的に優れた設計に向けて推進します。ただし、ソリューションを設計する方法を知る必要があります。

私は、テストに合格するために最小限のコードを書くだけでアプリケーションを成長させることができると主張する還元主義TDD哲学を支持しません。アーキテクチャについて考えることなく、これは機能しません。あなたの例はそれを証明しています。

ボブ・マーティンおじさんはこう言います：

テスト駆動開発を行っていない場合、専門家と呼ぶことは非常に困難です。ジム・コプリンは、私をこのカーペットのために呼びました。彼は私がそれを言ったことを好きではなかった。実際、彼の現在の立場は、テスト駆動開発がアーキテクチャを破壊しているということです。人々は他の種類の思考の放棄にテストを書き、テストをパスするために狂ったように彼らのアーキテクチャを引き裂き、彼は興味深い点を持っているので、それは儀式を乱用し、規律の背後にある意図を失う興味深い方法です。

あなたがアーキテクチャを考えていない場合、代わりにあなたがしていることはアーキテクチャを無視し、テストを一緒に投げてそれらを通過させることである場合、あなたはそれが建物にとどまることを可能にするものを破壊していますシステムの構造と、システムが構造の完全性を維持するのに役立つ堅実な設計決定。

単にテストをまとめて投げて、10年ごとに10年ごとに合格させ、システムが生き残ると仮定することはできません。私たちは地獄に進化したくありません。そのため、優れたテスト駆動開発者は常に大局を考えて、アーキテクチャの決定を意識しています。

非常に良い質問です...そして、@ Robert以外のほとんどの人と意見を異にする必要があります。

書き込み

return 120;

階乗関数が1つのテストに合格するのは時間の無駄です。それは「ごまかし」ではなく、文字通りred-green-refactorに従ってもいません。それは間違っています。

その理由は次のとおりです。

• 階乗の計算は機能であり、「定数を返す」のではありません。「return 120」は計算ではありません。

• 「リファクタリング」引数の見当違い。5と6の2つのテストケースがある場合、階乗をまったく計算していないため、このコードはまだ間違っています。

  if (input == 5) { return 120; } //input=5 case
  else { return 720; }   //input=6 case
  

• 「リファクタリング」引数に文字通り従えば、5つのテストケースがある場合、YAGNIを呼び出し、ルックアップテーブルを使用して関数を実装します。

  if (factorialDictionary.Contains(input)) {
      return factorialDictionary[input]; 
  }
  throw new Exception("Input failure");
  

これらのどれも実際には何も計算していません。そして、それは仕事ではありません！

単体テストを1つだけ記述した場合、1行の実装（return 120;）は正当です。120の値を計算するループを書く- それは不正行為になるでしょう！

このような簡単な初期テストは、エッジケースを検出して1回限りのエラーを防ぐのに適した方法です。実際には、5は最初に入力する値ではありません。

ここで役に立つかもしれない経験則は、ゼロ、1、多く、ロットです。0と1は、階乗の重要なエッジケースです。ワンライナーで実装できます。「多くの」テストケース（5！など）は、ループの作成を強制します。「ロット」（1000 !?）テストケースでは、非常に大きな数を処理するための代替アルゴリズムを実装する必要があります。

テストが1つしかない限り、テストに合格するために必要な最小限のコードはreturn 120;であり、テストがない限り、そのために簡単に保持できます。

これにより、このメソッドのその他の戻り値を実行するテストを実際に記述するまで、さらに設計を延期できます。

テストは仕様の実行可能なバージョンであり、その仕様がすべてf（6）= 120ということだけであれば、それは法案に完全に適合することを覚えておいてください。

このような方法で「チート」できる場合は、単体テストに欠陥があることを示唆しています。

1つの値で階乗法をテストするのではなく、値の範囲でテストします。ここでは、データ駆動型テストが役立ちます。

ユニットテストを要件の明示として表示します。テストするメソッドの動作をまとめて定義する必要があります。（これは行動駆動開発として知られています -その未来;-)）

だから、自問してみてください-誰かが実装を間違ったものに変更したとしても、あなたのテストはまだパスするでしょうか、それとも「ちょっと待って！」

それを念頭に置いて、あなたの唯一のテストが質問のテストであった場合、技術的には、対応する実装は正しいです。この問題は、定義が不十分な要件と見なされます。

さらにテストを書くだけです。最終的には短くなります書くのなります

public long CalculateFactorial(long input)
{
    return input <= 1 ? 1 : CalculateFactorial(input-1)*input;
}

より

public long CalculateFactorial(long input)
{
    switch (input) {
       case 0: return 1;
       case 1: return 1;
       case 2: return 2;
       case 3: return 6;
       case 4: return 24;
       case 5: return 120;
    }
}

:-)

「OK」の値が十分に小さい場合、「チート」テストの作成は問題ありません。ただし、リコール単位テストは、すべてのテストに合格した場合にのみ完了し、失敗する新しいテストを作成することはできません。大量のifステートメント（またはさらに良いのは大きなswitch / caseステートメント:-) を含むCalculateFactorialメソッドが本当に必要な場合は、それを行うことができます。また、固定精度の数値を扱うために必要なコードこれを実装するのは有限です（おそらくかなり大きくていですが、おそらくプロシージャのコードの最大サイズに関するコンパイラまたはシステムの制限によって制限されます）。この時点で本当にすべての開発は、あなたがすべてのブランチ以下によって達成することができるものよりも短い時間の量で結果を計算するためのコードを必要とし、テスト書くことができますユニットテストによって駆動されなければならないことを主張するかの声明を。

基本的に、TDDは要件を正しく実装するコードを書くのに役立ちますが、良いコードを書くことを強制することはできません。それはあなた次第です。

共有してお楽しみください。

ここでのRobert Harveysの提案には100％賛成です。テストに合格するだけでなく、全体的な目標にも留意する必要があります。

「入力の特定のセットで動作することが検証されている」というあなたの痛みの解決策として、xunit理論などのデータ駆動型テストを使用することを提案します。この概念の背後にある力は、入力から出力への仕様を簡単に作成できることです。

階乗の場合、テストは次のようになります。

    [Theory]
    [InlineData(0, 1)]
    [InlineData( 1, 1 )]
    [InlineData( 2, 2 )]
    [InlineData( 3, 6 )]
    [InlineData( 4, 24 )]
    public void Test_Factorial(int input, int expected)
    {
        int result = Factorial( input );
        Assert.Equal( result, expected);
    }

さらに、テストデータ提供を実装することもできます（それは IEnumerable<Tuple<xxx>>）を、数学的な不変式をエンコード。たとえば、nで繰り返し除算するとn-1が生成されます。

このtpは非常に強力なテスト方法であることがわかりました。

それでもチートできる場合は、テストだけでは十分ではありません。さらにテストを書く！あなたの例では、入力1、-1、-1000、0、10、200のテストを追加しようとします。

それでも、もしあなたが本当にカンニングをするなら、無限のif-thenを書くことができます。この場合、コードのレビュー以外には何も役に立ちません。あなたはすぐに受け入れテスト（他の人によって書かれました！）

単体テストの問題は、プログラマーがそれらを不要な作業と見なすことです。それらを見る正しい方法は、あなたの仕事の結果を正しくするためのツールとしてです。したがって、if-thenを作成する場合、考慮すべき他のケースがあることを無意識に知っています。つまり、別のテストを作成する必要があります。不正行為が機能していないことに気付くまで続き、正しい方法でコーディングする方が良いでしょう。まだ終了していないと感じる場合は、終了していません。

テストの選択は最良のテストではないことをお勧めします。

私は次のことから始めます：

最初のテストとしてfactorial（1）

2番目としてfactorial（0）

3番目としてfactorial（-ve）

そして、自明ではないケースを続けます

そして、オーバーフローケースで終わります。