0

だから私はカートサービスをシミュレートするという学術的な問題を抱えています。

Cart は、OrderItem の追加と、特定のカートの合計価格を計算する別の役割をサポートします。これは、合成と IPricingCalculator への委譲を介して行われます。

public class Cart
{
private List<OrderItem> _items;
private IPricingCalculator _pricingCalculator;

public Cart(IPricingCalculator pricingCalculator);
public addItem(OrderItem);

public double totalPrice()
{
double price = 0.0;
for (OrderItem orderItem: _items)
    price += _pricingCalculator.getPrice(orderItem);
}

}

IPricingCalculator は getPrice メソッドを次のようにサポートします。

public interface IPricingCalculator
{
double getPrice(OrderItem item);
}

CustomPriceCalculator は IPricingCalculator インターフェイスを実装します

public class CustomCalculator implements IPricingCalculator
{
private List<IPriceRule> _priceRules;
public double getPrice(OrderItem item); // return the price according to the first rule that matches
}

CustomCalculator を TDD の方法で実装しました。これらは私のテストの一部です。

@Test
public void FreeItemCostNothing();
public void SpecialItemCostHalf();
public void BulkPurchaseCostsQuater();

等々。

また、CustomCalculator が正常に動作していることは確かです。

しかし、TDD によると、カートを実装するための次のステップは何なのかわかりません。カートが行うことになっているのは、OrderItem のコレクションを管理し、コレクションで getPrice メソッドを折りたたむことだけです。両方のクラスに同じ徹底的なテスト スイートを使用する必要がありますか?

つまり、カートのテストには、次のようなテストも含める必要があります-

@Test
public void TenFreeItemCostNothing();
public void FiveSpecialItemsAndBulkPurchaseCostsHalfAndQuarter();

などなど

ありがとう ：）

4

2 に答える 2

0

私があなたの説明を理解している限り、あなたCustomPriceCalculatorはテスト主導の方法で実装しました。つまり、次の手順に従ってください。

  1. 失敗する単体テストを書く
  2. 失敗したテストを成功させる
  3. リファクタリング

あなたは興味深い問題に直面しています。これは通常、完全な TDD テスト サイクルに従わないことによって引き起こされます。次のようになります。

  1. 不合格の受け入れテストを書く
  2. 失敗する単体テストを書く
  3. 失敗したテストを成功させる
  4. リファクタリング
  5. 不合格の受け入れテストに合格するまで、手順 2 ～ 4 を繰り返します。

受け入れテストはエンド ツー エンドのテストであり、アプリケーション スタック全体を切り抜けます (たとえば、UI からビジネス ロジック、データベース、およびその逆)。これは、コードに構造を与えるために必要です。コードに欠けている部分と、実装する必要があるコラボレーターを定義できます。また、プログラミングをアプリケーションの必要な部分に集中させるためのガイドも作成します。

TDD を学習するつもりなら、Growing Object-Oriented Software, Guided by Tests の学習に時間を費やすことをお勧めします。TDD を適切に実行するために必要なすべてを提供します。

于 2013-09-09T10:33:43.983 に答える