20

OK、私は近年、開発にアジャイル プラクティスを公然と採用している会社で働いています。単体テストとコードの品質は向上しています。私たちが今も取り組んでいる領域の 1 つは、自動化された受け入れテストの分野で最適なものを見つけることです。よく形成されたユーザー ストーリーを使用して、テスト駆動型の方法でコードを実行したいと考えています。これにより、自動化できる各ユーザー ストーリーの受け入れレベル テストも得られます。

これまでに、Fit、Fitnesse、Selenium を試しました。それぞれに利点がありますが、実際の問題もありました。Fit と Fitnesse については、物事が複雑すぎると感じずにはいられず、それらを使用して多くの技術的な問題が発生しました。ビジネスはこれらのツールを完全に取り入れているわけではなく、常にスクリプトを維持することに特に熱心ではありません (また、テーブル スタイルの大ファンでもありません)。Selenium は非常に優れていますが、速度が遅く、リアルタイムのデータとリソースに依存しています。

現在検討中のアプローチの 1 つは、JUnit フレームワークを使用して同様の機能を提供することです。JUnit を使用して小さな作業単位だけをテストするのではなく、それを使用して (JUnit フレームワークを使用して) テストを作成し、アプリケーションの受け入れレベルの範囲をカバーしてみませんか? つまり、新しいストーリー (「ユーザーとして、ポリシーの基本的な詳細を確認したい...」) を取り上げ、JUnit でテストを作成します。これは、ポリシーの詳細リンクのエントリ ポイントでアプリケーション コードの実行を開始しますが、すべてのコードをカバーします。そして、スタブ化されたデータ アクセス レイヤーにロジックを落とし、アプリケーションの次のページに転送するポイントに戻り、そのページでユーザーに表示されるデータをアサートします。

これには次の利点があるように私には思えます。

  • シンプルさ (追加のフレームワークは不要)
  • 継続的インテグレーション ビルド サーバーとの統合に手間がかからない (既に JUnit テストを処理しているため)
  • チームにはすでに完全なスキルセットが存在します (結局のところ、単なる JUnit テストです)

そして欠点は次のとおりです。

  • 顧客の関与が少ない (ただし、受け入れテストが作成される最初の場所で、ユーザー ストーリーの作成に深く関与しています)
  • おそらく、JUnit クラスのユーザー ストーリーと受け入れ基準を理解する (または理解させる) ことは、Fit や Fitnesse のフリーテキスト仕様よりも難しいでしょう。

だから、私の質問は本当に、この方法を試したことがありますか? 考えたことはありますか？あなたの考えは何ですか？このアプローチの好きなところと嫌いなところは何ですか? 最後に、このアプローチよりも好きな理由または嫌いな理由を説明できる場合にのみ、代替フレームワークについて言及してください。

4

7 に答える 7

12

受け入れテスト フレームワークに JUnit を使用した私の経験。

私たちの会社は、FitNesse から始めて JUnit に移行したという非常に似たようなことをしました。私たちがこれを行った主な理由は、FitNesse がすでに Java の上に置かれていたためで、JUnit への切り替えは簡単でした。FitNesse は、私たちのニーズに合わないようでした (しゃれた意図はありません)。

JUnitを使用することの長所と短所は次のとおりです。

長所：

  • JUnit は (Java であるため) 多くの柔軟性を備えているため、内部ドメイン固有言語[Fowler] を作成するのは比較的簡単です。ドメインの専門家 (ソフトウェア エンジニアではない) が簡単に読み書きできるように、DSL を変更できます。
  • JUnit であるため、Eclipse を IDE として使用できます。これにより、オートコンプリート、構文チェック、デバッグなどが可能になります。
  • このアプリケーション専用に、UI への CORBA インターフェイスがあります。Java もこの CORBA インターフェイスを簡単に使用できます。

短所：

  • 人々は JUnit と聞いて単体テストを考えます。人々が受け入れテストを「JUnit テスト」と呼び始めると、これは混乱を招きます。
  • 簡素化されたテスト環境を提供するには、フレームワークの拡張と DSL の開発に時間を費やす必要があります。

要約すると、時間をかけて独自のドメイン固有のテスト環境に拡張する意思がある場合、JUnit は受け入れテストで問題なく機能します。そうでなければ、もっと独創的なものを他の場所で探すと思います。

于 2012-09-27T22:59:07.347 に答える
6

ビジネスと UAT
ビジネスはほとんどの場合、遅かれ早かれテスト ツールへの関心を失います。結局のところ、彼らはテスターではなくビジネスであるため、テスト スクリプトの作成や保守にはあまり関与しません。彼らはビジネスであり、ビジネスをしたいのです。彼らの観点からすると、テスター/開発者/その他の IT 担当者は、一定の品質のソフトウェアを提供する責任があります。
アジャイルがあなたのやり方であり、ビジネスからある程度のコミットメントを得たとしても、彼らがすべてのスプリント/イテレーションまたはあなたが持っているものでテスターのように振る舞うことを期待しないでください. それは本当に彼らの仕事ではありません。
余談ですが、ユーザー受け入れテストはユーザーによって実行される手動テストであるため、ユーザーは要求した製品であると言えます。
したがって、機能 (または機能のセット) の準備ができたら、ビジネス向けのプレゼンテーションを行い、それで遊んでもらい、それが必要なものであると言ってもらいます。すべての反復でこの機能をチェックするように強制しないでください。

受け入れテストに戻りましょう。クライアントからの話があるときはいつでも、テスト インフラストラクチャにテストを実装します。あなたはそれを書き、実行し、維持します。機能のテストを行い、ADD/BDD/TDD または任意の名前で開発を推進することが賢明な場合があります。このテストは、次の反復で回帰テスト スイートに貢献することは明らかです。

したがって、私の見解では、ビジネスは、特に一連の機能が成長する場合、テストの作成/維持に熱心ではありません。それと戦うのではなく、それに適応してください。新機能のイテレーションの最後に、(手動の) ユーザー受け入れテストだけを実行させます。あなた自身のために、彼らが欲しい機能のテストを作成してください。各機能の機能受け入れテストを作成します。これらのテストを回帰テスト スーツにしましょう。それを維持するのはあなたの責任であることを受け入れてください。

受け入れテスト フレームワーク
JUnit ですね。次に、Web 用のWatiJとデスクトップ用のAbbotを試してください。これらのテストは単純な単体テストではないことに注意してください。実際のアプリケーションの機能をテストするものが必要で、特定のシナリオ/ビジネス プロセスを実行するテスト スクリプトが必要です。つまり、DRY、KISS、YAGNI、デザイン パターンなど、テスト対象のアプリケーションを作成するのと同じように、これらのテストを作成する必要があります。すべてが適用されます。最終的には、あなたが書いた他のソフトウェアをたまたまテストするソフトウェアを書くことになります。

このアプローチでは、これらのテストは大規模で複雑になりますか? 単体テストよりも大規模で複雑です。しかし、彼らは単一のユニットではなく、アプリケーション全体をテストしています。その上、それらは、最初に作成するアプリケーションよりもはるかに単純で小さくなります。

テスト フレームワークを作成しますか? このアプローチで成功したい場合は、テスト フレームワーク (実装されたアプリケーションに関する知識を持つテスト クラスとヘルパー クラスのコレクション) を作成します。ただし、JUnit を拡張することはありません。ここでの JUnit は、フレームワークで使用する API にすぎません。

于 2010-07-24T22:44:16.740 に答える
3

robotframework (www.robotframework.org) を試してみてください。私は何年も使用しています。ヘルシンキの Pekka Klarck が開発しました (Nokia Siemens Networks は最初からサポートしており、現在はオープンソースでもあります)。

robotframework は表形式のテスト ケースを使用し、HTML、CSV、またはプレーン テキスト (特定の文法で記述) をサポートします。Selenium 関数のインポートをサポートするライブラリ メカニズムがあります。Python または Java で robotframework のライブラリを作成できます。

受け入れテスト フレームワークとしての JUnit の場合、もちろん可能ですが、それを行う価値はありません。高レベルのテストは、ソフトウェアの内部実装に依存する必要はほとんどありませんが、JUnit (単体テスト フレームワーク) を使用して受け入れテストを作成すると、内部関数呼び出しなどに多くの依存関係が導入されます。高レベルのテストが影響を受けるべきではないソフトウェア設計に変更がある間、これは大きな頭痛の種になります。

于 2012-06-23T05:26:55.660 に答える
3

その道をたどる場合のいくつかの推奨事項：

  • 通常のテストよりも実行速度が遅くなり、依存関係が増える可能性があるため、受け入れテストを別のプロジェクトに配置します。
  • テスト フィクスチャでモデルをセットアップするためのビルダーを作成します (流暢なインターフェイスを使用する場合もあります)。これは、テストに必要なオブジェクトのセットアップが、最も退屈で保守が難しい部分であることに気付くためです。
  • Groovy とSpock Frameworkを調べてください。これは JUnit と互換性がありますが、テストを読みやすくするための優れた DSL を提供します。
于 2011-12-06T04:44:02.620 に答える
1

長所と短所についていくつかの良い点を述べました。追加できますか:

利点: データベースや Web サーバーがなくてもすべてをテストできるというアイデアが気に入っています。これは、コードの理解とリファクタリングに非常に役立ちます。

欠点:

JUnit コードは複雑になり、保守が難しくなります。Junit テスト内のコードとユーザー間のすべてのやり取りを再現する必要があり、これはすぐに複雑になります。1 つのエントリ ポイントをテストするだけであれば、これでうまくいく可能性がありますが、複数の画面 (ウィザードなど) をテストしている場合は、すぐに脆弱で管理しにくくなる可能性があります。私の経験では、ほとんどの場合、問題はページ間の配管コード、またはページに必要なセットアップ コードです。

考慮すべきもう1つのことは、あなたがやろうとしていることの柔軟性です。Fitnesse を使用すると、バグを発見した場合に別のテストを簡単に追加できます。実際、これが Fitnesse の背後にある考え方です。「ユーザー」は、コードを変更することなく別のテストを追加できます。この価値を過小評価しないでください。

そこで、次の 2 点を提案します。

1) 試してみてください。ユーザー ストーリー (複雑すぎず、単純すぎず) を取り上げ、JUnit で実行します。あなたが行ったことを Selenium/Fitnesse などと比較し、価値があるかどうかを確認してください。1. 実際にバグを見つけているかどうか、2. もろくて管理しにくいコードを作成しているかどうかを確認してください。

2) Fitnesse によって作成されたデータを JUnit テストへの入力として使用できますか (したがって、Web サーバーなどの必要性がなくなります)。データを読み取って、Java クラスのメソッドを直接呼び出すこともできます。ここでも、セットアップとデータベース コードに問題がある可能性があります。

于 2010-04-23T07:32:31.653 に答える
0

私見は良い考えではありません。あなたが言及した 2 つの短所とは別に、あらゆる種類の Web/UI/接着剤のシナリオを処理する受け入れテスト フレームワークを構築するために必要な膨大な労力についてはどうですか? あなたの組織は JUnit の上により精巧なフレームワークの構築に投資する必要があるため、「シンプルさ (追加のフレームワークは必要ありません)」という点は正しくありません。JUnit以上かもしれません。

于 2010-04-22T21:18:15.663 に答える