非常に長いモカ試験をするのは悪い習慣ですか？

Question

単体テストを行う場合、それぞれのケースは短くて排他的です。しかし、今、私はこのように、私は例えば、いくつかの密接に関連するステップを含んで長いシナリオ、持っている、Seleniumでエンドツーエンドのテストを書いている：

1. ユーザーを
2. ユーザーログイン
3. ユーザーポストANを登録記事
4. ユーザー編集その記事

は、任意のエラーは、私は他のテストを続けることを期待していなかったキャッチされるべきです。だから、上記のすべてをただ一つのitブロックに入れなければならないようです。しかしもちろん、これはブロックを非常に長くし、大きなタイムアウトを設定しなければならず、長い仕上げ時間などが必要です。

これは悪い習慣ですか？

Answer 1

本当にどれくらいの期間ですか？ウェートドライバーのボットが適切な待機設定をしている場合、これは理想的には10秒未満でなければなりません。 私が提案したいヒントがいくつかあります。あなたがすでに受け入れテストの興味深いパターンを使用しているようだ

孤立、再現性のあるテスト
。 今年（2017年）のクラフトカンファレンスでの彼の講演で、Dave Farleyは、各実行が新しく作成されたユーザーの名前で行われるたびに、無限回数繰り返すことができるテストを書くというアイデアを説明しました。

"db restore"の問題に取り組む興味深いアプローチで、多くのプロジェクトがCI/CDワークフローで苦しんでいるのがわかります。それは復元する必要はありません。それは共通の状態にリベースされるかもしれませんが、すべてのテストはすべての必要な要素を新しいIDでプロビジョニングします。例えば、テストの最初の実行はuserid1234で実行され、次はuserid1235と一緒に実行されます。

したがって、プロセスへの登録を含むアプローチは、実行を分離するのに役立ちます。トレードオフは、基本データ（初期データベース状態の一部である可能性がある）と追加されるものが何であるかを調べる必要があるということです。

伝統的な考え方は、登録、ログイン、および機能を独立してテストすることです。トレードオフは、登録が失敗した場合、それ以上のテストは機能しないということです。受け入れテストについて語った講演の映像に

リンク：

http://www.ustream.tv/recorded/102892932

ページがそう

オブジェクト、私はちょうど1つの中に上記のすべてを置く必要があると思われますそれはブロックする。

いくつかは既に古くなっていると考えていますが、ページオブジェクトパターンはしばらくの間残っているようです。あなたの 'それ'ブロックは本当に複雑ではありません。あなたのテストでは、基本的に何が起こっているのかについての純粋な英語の説明を見つけるべきです。

it('should deny access with wrong creds', function() { 
    LoginPage.open(); 
    LoginPage.login('Luo', 'SuperSecretPwd'); // Use better forms of Auth 
    LoginPage.submit(); 
    expect(LoginPage.flash.getText()).to.contain('Hi Luo!'); 
}); 

アイデアは、与えられたページがどのように実装されるかの基本的に任意の技術的な詳細（CSSグリッド対テーブルなど）は、これらのオブジェクトに隠された保たれるべきであるということです。 あなたのテストはエラーが起こりにくく、単なる人間だけが理解することができます。ページオブジェクトパターンに

詳細情報：この詳細な回答のため

http://webdriver.io/guide/testrunner/pageobjects.html
https://martinfowler.com/bliki/PageObject.html