4

UI ドライバーを使用して BDD (Behavior Driven Design) テストを実装できますか?

たとえば、次の代わりに Web アプリケーションが与えられたとします。

  • バックエンド用のテストを作成してから、フロントエンド用の Javascript でさらにテストを作成する

するべきか：

  • 実際のブラウザでマウスクリックなどをシミュレートする Selenium マクロとしてテストを記述しますか?

この方法で行う利点は次のとおりです。

  • テストは、複数の言語ではなく、1 つの言語で記述されています。
  • 彼らは UI に焦点を当てているため、開発者は外から中へと考えることになります。
  • それらは実際の実行環境 (ブラウザー) で実行されるため、次のことが可能になります。
    • さまざまなブラウザーをテストする
    • 異なるサーバーをテストする
    • 実際のパフォーマンスについての洞察を得る

考え？

4

6 に答える 6

3

これは、WPFテストツール（WipFlash）を使用し、BDDのような方法でNUnitテストを記述したC＃アプリケーションに対して行いました。

例えば

Given.TheApplicationWindowIsOpen();
When.I.Press.OKButton();
The.Price.ShouldBeCalculated();

言うまでもなく、多くのDSLを自分たちでコーディングする必要がありました。しかし、それはビジネス/顧客が読めるソリューションになります。

于 2011-01-03T12:06:30.760 に答える
2

WatiN で SpecFlow を使用してみてください: (ここで .NET を使用しているかどうかはわかりません)

http://msdn.microsoft.com/en-us/magazine/gg490346.aspx

于 2011-01-03T12:04:49.813 に答える
1

Webテストの場合は、WebDriverを試すことができます。Seleniumチームは、現在WebDriverの統合に忙しくしています。WebDriverを作成したGoogleのSimonStewartが、Seleniumとの動作の違いについてブログに書いています。

WebDriverは、ブラウザごとに異なるテクノロジを使用します。Internet Explorerの場合、WebDriverはMicrosoftのUI自動化を使用します。これは、@BrianAgnewが言及したWipFlashが基づいているのと同じテクノロジです。これは、ボタンをクリックするふりをするのと同じくらい近いです。Simonのブログは、このアプローチがSeleniumのJavascriptソリューションよりも強力である理由を示しています。

WebDriverはSeleniumサイトから入手できますが、Seleniumの一部としてまだ完全には実装されていません。

于 2011-01-03T12:28:58.803 に答える
1

BDDやユースケース主導のテストでは、テストの実行内容を伝達できることが重要です。多くのテストスイートの問題は、書き込み後の誰も、テストが何をしているのかを正確に確信していないことです。これは、専門外の言語で書く場合に非常に頻繁に発生します。専門化は必ずしも特別な言語を意味するわけではありませんが、1つの言語で十分に抽象化されているため、何が起こっているのかが明確になります。

たとえば、多くのテストには次のようなコードがあります（擬似コード、特定のフレームワークは選択しません）。

object = createBrowser()
response = object.gotoURL( "http://someurl.com" );
element = response.getLink( "Click Here" );
response = element.doClick();

これは、誰かがビジネスドライバー（おそらく製品マネージャー、またはユーザー）にすばやく変換するのは困難です。代わりに、特殊な機能、または冒険心がある場合は言語を作成したいので、次のことができます。

GotoURL http://someurl.com/
Click link:Click Here

Seleniumとそのマクロまたはインターフェイスは、この点でまだかなり低レベルです。それらを使用する場合は、少なくともそれらの周りにいくつかのラッパーを作成します。

もちろん、 TestPlanという製品を使用することもできます。バックエンドにSeleniumがあり、高レベルのAPIと、テスト用のカスタム言語を公開しています。また、Webだけでなく、EメールやFTPなども含まれています。 上記のサンプル言語はTestPlanスニペットです。

于 2011-01-05T18:36:42.307 に答える
0

実際には、両方を行うことができます-ユーザー中心のドライバーインターフェイスを作成します（GUI / tech / implに依存しません）。次に、UIDriverとAPIDriverを記述し、特定のテストを実行するドライバーを選択できます。UIの実行は通常遅くなります（procから外れると、コントロールは再描画されますが、どういうわけか最初はより高いレベルの信頼性が作成されます）。APIの実行ははるかに高速です（procでは、セットアップが簡単です-分解）。

ここでの秘訣は、WhatとHowを分離することです。そうしないと、ObscureTestsと高度なテストメンテナンスが発生します。自動化ではなく、テストに重点を置くようにします。

于 2011-09-28T05:32:53.790 に答える
0

確かに、この方法で受け入れテストの一部を実行できますが、ほとんどの BDD 支持者は、すべてのテストでこれを使用することをお勧めしません。そしてもちろん、真の BDD 支持者はそれらをテストとは呼びません...

RSpec Book では、受け入れテスト (またはシナリオ) を最初に (主にCucumberで) 記述し、単体テストを ( RSpecで) 内側のサイクルで記述し、従来の TDD に似た 2 レベルのサイクルを提唱しています。

受け入れテストの外側のサイクルでは、Selenium などのツールを使用して、UI を介してアプリケーション全体を駆動することもできます (RSpec Book の著者はこれについて 1 章を費やしています)。ただし、単体テストには適していません。

UI を介してアプリケーション全体を実行するテストは、繰り返し可能にするのが難しく、単体テストよりも遅く、壊れやすい傾向があります。

于 2011-01-03T12:48:33.143 に答える