it-swarm-ja.com

回帰テストのためのベストプラクティス

こんにちは、

プラットフォームとしてWordPressを使用して、ブログ以外の複雑なソリューションをクライアントに提供している他の人が、自動化 回帰テスト に使用しているものを聞きたいのですが。

"回帰テスト"という用語に慣れていない人のためにウィキペディアは次のように定義しています:

回帰テストは、プログラムを再テストすることによって、プログラムへの変更(バグ修正や新しい機能など)が行われた後にソフトウェアエラーを発見しようとするあらゆる種類のソフトウェアテストです。回帰テストの目的は、バグ修正などの変更によって新しいバグが発生しないようにすることです。

もっと言うと、ウィキペディアは次のように述べています。これはまさに私が今プロジェクトで経験していることです。

ソフトウェアが修正されるにつれて、新しい障害の出現および/または古い障害の再出現が非常に一般的であることが経験からわかっています。修正が不適切なリビジョン管理手法(またはリビジョン管理での単純な人的ミス)によって失われるために、再発が起こることがあります。多くの場合、問題の修正は、最初に確認された狭いケースでは問題を解決しますが、ソフトウェアの有効期間中に発生する可能性のあるより一般的なケースでは解決しないという点で「脆弱」です。多くの場合、ある分野の問題に対する修正が誤って別の分野のソフトウェアのバグを引き起こします。最後に、ある機能が再設計されたときに、その機能の元の実装で行われたのと同じ間違いのいくつかが再設計で行われたことがよくあります。

アクションとフィルタのグローバルな性質を考えると、クライアントが要求する機能を追加するにつれて複雑さが増し始め、複雑なプラグインを安定させることが難しくなります。特にWP_Queryへの呼び出しを多く使用してデータベースを更新する場合たくさん。

私の考えている解決策は、一連の"テストケース"で回帰テストを設定し、"テストスイート"を構成することです。概念上、HTTP GETリクエストのHTML出力をテストするときはそれほど難しくありません。しかし、管理コンソールからログインしたときやjQueryのやり取りをテストするためにテストする必要がある場合は、もう少し複雑になります。

私はここでベストプラクティスを集めることができると期待してコミュニティウィキとしてこれを設定していますが、他のWordPress専門家が使用している場合はプロセスを聞くことが本当に心配です。

21
MikeSchinkel

WPテストスイートがそれほど壊れておらず、WPが実際に適切にテストされるように設計され、書かれていれば、PHPUnitは思い浮かぶでしょう。 ;-)

もっと真剣に、単体テストなどを使って機能的な観点からあなたが望むすべてのプラグインをテストすることができます。問題は、これらのテストがWPアップグレードによってもたらされるわずかなチャンスをキャッチすることを保証するものではないことです。カスタマイズされたWPインストールにプラグインされると機能し続けることはもちろんです。

私が見たカラフルなものの中では起こります:

  • WP AP​​Iの微妙な変更は、プラグインの機能に影響を与えます。あなたが使っているフックは、用語IDを取得するのに慣れていて、今は用語分類IDを得ています。 (あなたのテスト用語が便利に両方のために同じidを持つことは良いことです)。

  • WP AP​​Iが微妙に変更されているため、不正な入力として以前に予想されていたfalseの代わりにWP_Errorオブジェクトが返されます。

  • あなたのプラグインはmu-pluginsフォルダの中から追加され、微妙に異なるコードフローをもたらします。

  • あなたのプラグインはmemcachedや他の永続ストアが有効になるまではうまくいきました。

  • あなたのプラグインは軽蔑されたswitch_to_blog()が呼ばれるまでうまくいきました。

  • プラグインは呼び出されるとそれが存在するフックを変更し、無意識のうちに副作用としてそれを中断します。

  • プラグイン(un?)は、故意ではないにもかかわらず、物事が壊れて見えるようになるまで、入力または出力データと混同します。

私はリストを拡大し続けることができましたが、それらは私自身のプラグインを壊した重要な項目になるでしょう。 2つの項目は単体テストで間違いなく捕獲可能です。次の2つも同様に、あなたが十分に辛抱強いなら、私はWPが起こったときに物事が動く方法を変えてはならないと主張するでしょう。 switch_to_blog()のバグのある実装を回避するテストはありません。そして最後の2つは絶望的にテスト不可能です。

ああ、そして...添付ファイル、自動ドラフト、リビジョン、メニュー項目の猛攻撃、そしてそれが投稿テーブルに格納されていないものについて私が始めてもいけません。

がんばろう... :-)

10

Selenium を強く検討する必要があります。

それはあなたが行動(例えばフォームへのデータの入力、リンクのクリック)を記録することを可能にし、そしてあなたは主張を実行することができます。それはまたPHPUnitと統合します。 2分間のデモをチェックすることを強くお勧めします。

7
Ethan Seifert

Seleniumはおそらく使用可能ですが、現代では Codeception の方が使いやすくなると思います。最も単純なvisual回帰テストでは、 スクリーンショットを撮る拡張機能 があり、それらを自動的に比較します。

もちろん、Codeception WebDriver テストはさらに進んでfunctional回帰テストを実行できます。フォームへの入力と送信、サイト上のボタンとリンクのクリック、JSの実行などができます。FirefoxやChromeなどの実際のブラウザをテストで使用したり、ヘッドレステストを実行したりできます。 PhantomJS で。つまり、プラグインのWebDriverテストを実行することもできます Travis CIでのビルドプロセスの一部として 必要に応じて。

WordPress固有のライブラリもいくつか用意されているので、すぐに使い始めることができます。

1
J.D.