私は現在、サーバー側の Rails 4 とクライアント側の EmberJS に基づいて、かなり大きく複雑な Web アプリケーションをテストする方法を評価しています。このアプリでは、クライアントは安静な JSON API を介してサーバーと排他的に通信します。
これまでに Konacha に基づいて多くの単体テストを行ってきましたが、現在は統合/受け入れテストもセットアップする予定です。エンド ツー エンドのテストの作成を開始する必要があるかどうかはわかりません。そのため、サーバーの実行中のインスタンスを含めてテストするか、API とクライアント側の統合テストを個別に行う必要があるかどうかを判断します。
API とクライアントを個別に統合テストする場合、テストの作成と維持に 2 倍の労力がかかり、通信の小さな、小さな専門分野が存在する可能性があるため、現時点ではエンド ツー エンドのテストを選択することをお勧めします。キャッチできなかった API とクライアントの間。
私たちは、Konacha のようなモダンで高速なテスト フレームワークが好きなので、Selenium はあまり使いたくありません。少し古い感じがするだけでなく、性能がかなり悪いからです。それでも、サーバー上のモック データのインスタンス化とサーバーのリセットを制御する必要があります。なぜ、次のアプローチを思いついたのですか。
サーバーの状態を制御するために概念的に使用される Testing API を実装しました。たとえば、次のメソッドがあります。
GET /api/test/setup # Simple bootstrapping of the database, e.g. populate table with ISO language codes etc...
GET /api/test/reset # Reset the database, using `database_cleaner` gem
その後、konacha テスト ケースは、各テスト ケースの前後にそれぞれ と をsetup呼び出します。reset
このアプローチについてどう思いますか？