WordPress Webサイトの回帰テストのベストプラクティスですか？

こんにちは、みんな、

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

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

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

ウィキペディアによると、次のように語っています。これは、私が現在プロジェクトで経験していることです。

ソフトウェアが修正されると、新しい障害の出現や古い障害の再出現が非常に一般的であることが経験により示されています。修正が貧弱な改訂管理慣行（または改訂管理における単純な人為的ミス）によって失われるため、再出現が発生することがあります。多くの場合、問題の修正は、最初に観察された狭いケースでは問題を修正しますが、ソフトウェアの寿命にわたって発生する可能性のあるより一般的なケースでは修正しないという点で「脆弱」です。多くの場合、ある領域の問題を修正すると、別の領域でソフトウェアのバグが発生します。最後に、いくつかの機能が再設計されると、その機能の元の実装で行われたのと同じ間違いのいくつかが再設計で行われた場合がよくあります。

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

私の考えでは、一連の「テストケース」を使用して回帰テストを設定し、「テストスイート」を構成します。概念的には、HTTP GETリクエストのHTML出力をテストするのはそれほど難しくありません。ただし、管理コンソール経由でログインしたり、jQueryの相互作用をテストしたりするときにテストする必要がある場合は、少し複雑になります。

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

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

さらに深刻なことは、ユニットテストなどを使用して、機能的な観点から必要なプラグインをすべてテストできることです。問題は、これらのテストは、WPのアップグレードによってもたらされる微妙な可能性をキャッチすることを保証するものではなく、カスタマイズされたWPインストールにプラグインされると機能し続けることは言うまでもありません

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

• WP APIの微妙な変更は、プラグインの機能に影響します。たとえば、用語IDを取得するために使用しているフックが、用語分類IDを取得しています。（テスト用語が便利なように両方のIDを持っていることは良いことです）。

• WP APIの微妙な変更WP_Errorにより、以前falseは不正な入力として期待されていた値ではなく、オブジェクトを受け取ることになります。

• プラグインはmu-pluginsフォルダー内から追加されるため、コードフローは微妙に異なります。

• プラグインは、memcachedまたはその他の永続ストアが有効になるまで正常に機能しました。

• 軽pluginされたswitch_to_blog（）が呼び出されるまで、プラグインは正常に機能しました。

• プラグインは、呼び出されたときに常駐するフックを変更し、副作用として知らないうちにそれを中断します。

• プラグイン（un？）は、入力データまたは出力データを故意にいじって、障害がなくても物事が壊れているように見えるようにします。

リストをどんどん拡大していくこともできますが、それらは自分のプラグインを壊してしまう重要なアイテムです。この2つの項目は、おそらくユニットテストでキャッチできます。次の2つも同様に、あなたが十分忍耐強いなら、WPは事態が起こったときに物事の働きを変えてはならないと主張します。switch_to_blog（）のバグのある実装を回避するためのテストはありません。そして、最後の2つは絶望的にテストできません。

ああ、そして...添付ファイル、自動ドラフト、改訂、メニュー項目、そして最終的には投稿テーブルに保存されないものの猛攻撃を始めさせないでください。

がんばろう... ：-）

Seleniumを強く検討してください。

アクション（たとえば、フォームへのデータの入力、リンクのクリック）を記録してから、アサーションを実行できます。また、PHPUnitと統合します。2分間のデモをご覧になることを強くお勧めします。

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

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

始めるのに役立つWordPress固有のライブラリもいくつかあります。

• WPブラウザ
• WP Codeception