0

キュウリのテスト スイートの問題で立ち往生しており、それをデバッグする方法が思い浮かびません。

キュウリの機能のかなりの数のセットがあり、それらはすべて開発マシンに渡されます。問題は、ci サーバーで cucumber スイート全体を実行すると、いくつかのシナリオが失敗することです。それらを個別に実行すると、シナリオがフォームに入力しようとすると (明らかに) ランダムに成功し、失敗します (明らかにページ）。ランダムな失敗のため、ajax リクエストのタイミングの問題だと思いましたが、そうではないようです。なぜなら、本当に大きなスリープ (1 秒から 60 秒まですべてを試しました) を追加しても何も変わらないからです。このシナリオは、同じ順序で最初のシナリオで失敗している同じ手順を実行している別の 3 つのシナリオがあるため、さらに楽しいものです。最初のシナリオを削除しない限り、これらの手順は成功します。失敗するもの。

キュウリでこの種の奇妙さをデバッグするためのトリックはありますか? 機能 (これらのシナリオは常に開発マシンに渡されることに注意してください。問題は ci サーバーにあります)。

ありがとう！

4

1 に答える 1

0

また、CI でのみ再現する断続的なテストの失敗をデバッグする機会もありました。私の経験では、問題は常にいくつかの基本的な原因に要約されます。

  1. フロントエンドでの競合状態。たとえば、xhr コールバックがデフォルト値を追加する前に入力用のフォームを有効にします。
  2. 「楽観的」はフロントエンドから書き込みます。フロントエンド エンジニアは、結果を無視することで、PUT/POST 要求を含むアクションの応答性を高めることがあります。この場合、リクエストが完了するまで Cucumber を待機させる方法がないため、データベースの状態変化に対するテストはアプリケーションと競合します。
  3. テスト フィクスチャで利用できないリソースへのリクエスト。たとえば、サードパーティ API へのリクエストは CI からブロックされる可能性があります。URL がテスト環境で正しく構築されないことがあります。特に、Rails ヘルパーを使用せずに「手作業で」構築された場合です。

断続的な Cucumber の障害は、常にデバッグが困難です。あきらめてはいけない！テスト可能で競合のないフロントエンドを構築する方法を理解することは、努力する価値があります。capybara-webkit を使用して、CI のみの障害をデバッグできます。javascript コンソール出力を取得して CI に出力すると、javascript に出力を追加して、テストが失敗した時点までその状態をトレースできます。capybara-webkit をハックして、フロントエンドからのリクエストに関する情報を出力することもできます。例を次に示します: https://github.com/joshuanapoli/capybara-webkit/commit/96b645073f7b099196c5d3da4653606e98a453e4

于 2013-03-11T14:10:40.813 に答える