web-dev-qa-db-ja.com

(Angularjs)Webアプリの統合テストを行う方法

Webアプリケーションを開発しています。それは2つの部分で構成されます。ノードレストサーバーとangularjsクライアント。

アプリの構造は次のとおりです。RestServer <-> APIモジュール<-> Angular App

サーバーは現在十分にテストされています。単体テストと統合テストがあります。統合テストは実際のデータベースにアクセスし、残りのAPIをhttp経由で呼び出しています。これは、サーバーテストで取得できるレベルと同じくらい高いと思います。統合テストも高速に実行されます。サーバーのテスト方法が私のユースケースに十分であると確信しており、結果に満足しています。

しかし、私はangularjsアプリをテストする方法に苦労しています。関連するディレクティブとモジュールの単体テストがあります。これらを書くことは問題ではありませんでした。

ユーザーシナリオをカバーする統合テストを記述したいと思います。サインアップシナリオのようなもの:ユーザーがWebサイトにアクセスし、サインアップフォームに移動して、データを含むフォームを送信します。

Angularjsチームは ng-scenarios から 分度器 に移行しています。分度器はテストを実行するためにセレンを使用しています。したがって、2つのスコープがあります。アプリスコープとテストスコープです。

これで、使用できる3つの異なる抽象化を考えることができます。そして、どれが私に最適なのかわかりません。

  • APIモジュールのモック
  • 残りのサーバーをモックする
  • 完全なサーバーを使用する

APIモジュールのモック

この場合、サーバーをセットアップする必要はありません。すべてのインタラクションがブラウザーで実行されています

利点:

  • サーバーは必要ありません

不利益:

  • APIはブラウザースコープにあり、私はこれを改ざんする必要があります。

私はこのソリューションが本当に好きですが、Apiを模倣するのは難しいと思います。 Apiはbrowsersスコープで変更する必要があります。したがって、テストからブラウザに変更を送信する必要があります。これは 行うことができます ですが、テストスコープでmockedApi.method.wasCalledOnce()のようなアサーションを実行する方法がわかりません

残りのサーバーをモックする

利点:

  • クライアントは変更されません
  • 対処するスコープは1つだけ

不利益:

  • 残りのルートを設定する必要があります

Nodejsで完全なモックレストサーバーを作成できます。分度器テストはnodejsで記述されているため、サーバーの制御をテストで実行できます。テストを実行する前に、サーバーに応答方法を伝えることができます。このようなもの:server.onRequest({method: 'GET', url: '/'}).respondWith('hello world')

次に、wasCalledOnceのようなアサーションを実行できます

データベースでサーバー全体を使用する

各テストは完全なサーバーで実行され、要素をデータベースに追加できます。各テストの後、データベース内の予想される要素を確認できます

利点:

  • これらのテストが実行されている場合、アプリはテスト済みのユースケースで機能していることはかなり確かです

不利益:

  • 私はすでに残りのサーバーとのかなり激しい統合テストを行いました。これはまた同じように感じる。
  • セットアップはサーバー全体に依存します

現在の結論

  • APIをモックすると、サーバーとクライアントが完全に分離されます。
  • モックAPIを使用すると、より高いレベルのテストになりますが、偽のサーバーが必要になります
  • 完全な統合テストを実行すると、最高の信頼性が得られますが、これはサーバーコードにも大きく依存します。

私は何を選ぶべきですか?あなたならどうしますか?

31
user524824

私は分度器グーグルグループでこの同じ質問に答えたと思います。私はあなたと同じように、サーバーを必要とせず、すべてのテストコードを1か所(Protractor内)に配置し、Protractorとブラウザーの間で分割しないことを望んでいます。これを可能にするために、私は問題を自分の手に取り、Protractor内で実行される$ httpBackendサービスのプロキシを開発しました。これにより、$ httpBackendサービスを分度器で実行しているかのように構成できます。私はしばらくの間これに取り組んでおり、その時点でその十分に機能しています。あなたが見て、私が重要な何かを逃していないかどうか私に知らせていただければ素晴らしいです。

https://github.com/kbaltrinic/http-backend-proxy

4

特定のツールとは何の関係もない素晴らしい質問です。私は、大きな「グリーンフィールド」(つまり、ゼロから始めた)プロジェクトでも同じ問題に直面しなければなりませんでした。

ここに語彙の問題があります。「模擬」という言葉はどこでも使用されており、「統合テスト」と呼ばれるものは、より「完全なエンドツーエンドの自動機能テスト」です。ここで問題はありません。明確な表現が問題の解決に役立つというだけです。

あなたは実際に自分で正しい答えを提案しました:#2残りのサーバーをスタブします。 #1は実行可能ですが、すぐに開発および保守が困難になるでしょう。#3は優れたアイデアですが、UIテストおよびUI検証とは何の関係もありません。

バックエンドとは関係なく、フロントエンドの高い信頼性を実現するには、残りのサーバーをスタブするだけです。つまり、べき等の単純なRESTサーバーを開発します。 1つのhttpリクエスト。べき等の原則を維持すると、他のどのオプションよりも開発とテストが非常に簡単になります。

次に、1つのテストで、画面に表示されているもの(上部をテスト)とサーバーに送信されているもの(下部をテスト)のみをチェックするため、UIスタック全体が1回だけテストされます。

質問に対する完全な回答はブログ記事全体に値するはずですが、私が提案することから何をすべきかを感じていただければ幸いです。

宜しくお願いします

3
bdavidxyz

Angularコードの統合テストを作成するためのアプローチを次に示します。重要な概念は、さまざまな関数を、ただし、コードを適切に分離することは、これで成功するために重要です。

詳細: http://www.syntaxsuccess.com/viewarticle/angular-integration-tests

3
TGH

これは素晴らしい質問です。これは私がそれをする方法です:

既にangular関連するディレクティブとモジュールの単体テストがあるので、これは完璧です。

もう1つの完璧なことは、サーバーの統合テストが実際のデータベースにアクセスし、http上の残りのAPIが機能することを確認していることです。

angularとサーバーを同時に含む、いくつかの高レベルの統合テストを追加しないのはなぜですか?.

モックを回避できる場合は、可能であれば、追加のコードを維持するために作業を保存してください。

また、よく読んでください: http://blog.ericbmerritt.com/2014/03/25/mocking-is-evil.html

0
SHernandez

RESTサーバーをモックすることは、私の意見では最良の、よりクリーンなオプションです。Mountebank( http://www.mbtest.org )を試してください。)驚くべき仮想化サービスツール。

0
Bruno Santos