2

例を挙げましょう：
要件：次のルールに従って材料を作成します：
与えられた<100=>材料は緑
100<<300=>材料は黄色
>300=>材料は赤

私のテストクラス：

        class MaterialTest{
          MaterialConstructor materialCons
          public void testBuild(){
                 materialCons.setAmount(150);
                 Material material=materialCons.build();
                 assertEqual(material.getColor(),"Yellow");
              }
    }

知っていることから、私はmaterialCons.build（）;を実装する方法がありません。設計と分析の後、次のようにMaterialCosntructorを実装しました。

    public class MaterialConstructor {

         private Helper1 helper1;
         private Helper2 helper2

        MaterialConstructor (Helper1 help1, Helper2 help2){
      .................   
    }

    public Material build(Double among){
         part1=helper1.builpart(among);
        return helper2.construct(part1);
    }

}

私の最初のテストクラスでは、次のようなコードを含める必要があります。

helper1=createMock(Helper1)
helper2=createMock(Helper2)

materialCons=new MaterialConstructor (helper1, helper2)

.....................

expected(helper1.builpart(150)).andReturn(some result)
expected(helper2.construct(some result)).andReturn("Yellow")

結果として、この更新されたクラステストを取得できます。

  class MaterialTest{
         MaterialConstructor materialCons
        public void testBuild(){
            helper1=createMock(Helper1)
            helper2=createMock(Helper2)
            materialCons=new MaterialConstructor (helper1, helper2)
            expected(helper1.builpart(150)).andReturn(some result)
            expected(helper2.construct(some result)).andReturn("Yellow")
             materialCons.setAmount(150);
             Material material=materialCons.build();
             assertEqual(material.getColor(),"Yellow");

          }
            }

したがって、私のテストコードは、私のソースコードを書き込んだ後に更新されます！

これは何度も表示されます（仕様時に、問題を解決するためにどの依存関係クラスを使用する必要があるかを知るのは難しいため）。そうすると、ユニットテストクラスはソースコードを書いた後は常に時代遅れになります！

4

2 に答える 2

2

TDD の3 つの法則などの厳格な TDD ワークフローに従うことで、迷いは確実になくなります。

それを使えば、「設計と分析の後、MaterialCosntructor を実装しました...」というようなことはできません。

テストに合格するのに十分な量の本番コードのみを記述します

これは基本的に"Yellow"、最初の実装として返すだけであることを意味します。

次に、さらにテスト (緑、赤のマテリアル) を追加し、これらの追加のケースを処理するようにクラスを段階的に設計します。

于 2013-01-28T15:11:31.700 に答える
0

いいえ、オブジェクトをテストするための単体テストケースを用意するというあなたのアイデアは、非常に素晴らしいと思います。あなたの場合、クラスメンバーとクラスメソッドを設計したので、ソースコードを書いた後にテストクラスが時代遅れになるとは思いません..あなたを止めているように見える唯一のことは、EasyMockテストケースを書くことです..ここにいくつかの助けがありますIBM Developer Works Simulation Page ..

EasyMock readme自体によるもう1つのハイパーリンクもありますEasyMock ReadMe

于 2013-01-26T17:02:38.300 に答える