-5

少し挑発的なタイトルですみません。例を挙げます。車を作るためのプログラムを書く必要があるとします。テストプログラムは次のとおりです。

public void testCarBuilder()
{
  expectedCar=someCar;
  actualCar=carFactory.build(bigWhell, yellowBodyCar);
  assertEqual(expectedCar, actualCar);
}

車を作るには、車輪と車のボディをパラメーターとして持つ関数が必要であり、少なくともプログラムを分析する必要があります。この分析は、自然言語や UML で行うことも、プログラミング言語で直接書くこともできます。この分析を紙に書いて脳に残したり、ファイルに書いたりすることができます。解析はすでにプログラムの骨格です! したがって、テスト前に少なくとも 1 つのプログラム スケルトンが常に書き込まれます。開発作業がテストを書くことから始まるとしましょう sybyllin. 誰かが逆のことが可能である方法を私に示さない限り.

4

2 に答える 2

1

私はあなたの質問を、TDD を行うときにどのようにデザインが現れるかを知りたいかのように解釈します。

テストを作成するには、テストが相互作用する境界/表面/ファサードを定義する必要があります。この設計作業は前もって行われます。成長し、変化するデザインは、そのテスト境界の向こう側にあります。

あなたの（些細な）例では、テストが発見するのに役立つデザインはcarFactory. それはあまり役に立たないので、あなたのテストはそれほど良くないと思います.

TDD 内にはさまざまな流派があります。私が実践しているのは、外側と内側からテストすることです。システム境界にできるだけ近いテスト境界を選択します。たとえば、テストでユーザー インターフェイスのボタン クリックをシミュレートします。これを行うと、そのボタン クリックの反対側でシステム全体のデザインを自由に変更できます。

あなたの例では、なぜ車を作りたいのですか? ユーザーはこのコードをトリガーするために何をしましたか? また、達成したいことがうまくいったことをユーザーはどのように確認できますか? それはあなたがあなたのテストで持っているべきものです。

于 2013-08-01T06:24:37.263 に答える