0

受け入れテスト駆動開発 (ATDD) に関する質問があります。私のアプリケーションは、Web サイト、モバイル、デスクトップなどの複数のクライアントを持つ可能性のある REST サービスとして開発されています。ATDD の概念では、すべての機能をエンド ツー エンドのテストから開始する必要があります。私のサービスには、同じユースケースを提供する複数のクライアント アプリケーション (エンド) がある可能性があるため、受け入れテストを作成するときにどのアプローチを使用する必要がありますか? 受け入れテストは、REST サービスまたはクライアント アプリへの直接要求を入力として受け取る必要がありますか? または両方？受け入れテストが REST 要求から開始する場合、クライアント部分を省略していることは理解していますが、これはまったく問題ありません。これらがクライアントから開始する場合、すべてのクライアントに対して基本的に同じ機能テストを繰り返します。これらの境界の中間にとどまるアプローチを見つける必要があります。

4

2 に答える 2

1

@bcarlso が示唆しているように、受け入れテストはビジネス ルールの観点から記述できるため、特定のプラットフォームに固有のものではありません。

これらの仕様を使用して、各シナリオをエンドツーエンドで各プラットフォームにわたってテストすることは確かに可能であり、多くの組織がこれを行っています。しかし、非常に大規模で遅いテスト スイートで終わる可能性が高く、保守が困難になります。

Cucumber および同様のツール ATDD では、エンドツーエンドでテストすることは義務付けられていません。それらを使用して、1 つのクラスの単一のメソッドのように焦点を絞った動作を検証できます。

統合前に大多数の欠陥をキャッチする優れた単体テストを作成することに集中してください。貧弱な開発プロセスの QA として、自動化された受け入れテストに依存しないでください。少数の高レベルのエンド ツー エンド テストを使用して、アプリの主な成功パスをテストします。

ここにはトレードオフがあります。一部の統合関連の問題は、ネットをすり抜けてしまう可能性があります。根本原因分析を実行し、今後同様の不具合を回避する方法を決定してください。適切なレベルで追加のテストを追加します。プロジェクトを独自のテスト スイートで溺れさせないでください。

于 2013-03-30T02:47:37.210 に答える
0

ATDD を実践するとき、受け入れテストは別のユーザー インターフェイスにすぎないと考えています。そうは言っても、ビジネス層の UI の下でテストします。機能があると仮定します：

Given I have an addend of 5
and an augend of 3
When I calculate the sum
Then I should receive 8

このテストを実装すると、シームはビジネス層になります。Java/Spring タイプのアプリケーションを想定すると、私のテストは次のようになります。

@Given("I have an addend of (\\d+)")
public void addend(int addend) { this.addend = addend; }

@Given("I have an augend of (\\d+)")
public void augend(int augend) { this.augend = augend; }

@When("I calculate the sum")
public void calculate() {
    calculator = applicationContext.getBean(ScientificCalculator.class);
    actualResult = calculator.sum(addend, augend);
}

@Then("I should receive (\\d+)")
public void verifyResult(int result) { assertEquals(result, this.actualResult); }

すべてのテスト シナリオ パスの背後にあるビジネス ロジックを開発したらScientificCalculator、アプリケーションが機能的な観点から必要なことを実行することがわかります。これは UI を完全にバイパスするため、UI ごとにテストを複製する必要はありません。UI にはビジネス ルールが完全になくなり (良いことです)、XML、JSON、HTML など、好きな UI を前面に配置できます。Spring MVC を使用していると仮定すると、コントローラーは次のように単純になります。

@GET("calculate/sum/{addend}/{augend}")
public void addSomeNumbers(String addend, String augend) {
    result = calculator.sum(Integer.parseInt(addend), Integer.parseInt(augend));
    // Render the view with the result.
}

UIをまったくテストしますか？おそらく。ただし、主要なビジネス ルールは既存のテストでカバーされており、一般的に言えば、UI のバグは、誤解されたり誤って実装されたビジネス ロジックよりもリスクが低く、修正が容易であるため、それほど完全ではありません。

それが役立つことを願っています!

ブランドン

于 2013-03-28T00:17:53.917 に答える