3
WordPress Webサイトの回帰テストのベストプラクティスですか？
こんにちは、みんな、 自動化された回帰テストに使用しているプラットフォームとしてWordPressを使用して、クライアントにブログ以外の複雑なソリューションを提供している他の人の意見を聞きたいのですが。 「回帰テスト」という用語に慣れていない人のために、ウィキペディアでは次のように定義しています。 回帰テストとは、プログラムを再テストすることにより、プログラムの変更（バグ修正や新機能など）が行われた後にソフトウェアエラーを発見しようとする、あらゆるタイプのソフトウェアテストです。回帰テストの目的は、バグ修正などの変更によって新しいバグが発生しなかったことを確認することです。 ウィキペディアによると、次のように語っています。これは、私が現在プロジェクトで経験していることです。 ソフトウェアが修正されると、新しい障害の出現や古い障害の再出現が非常に一般的であることが経験により示されています。修正が貧弱な改訂管理慣行（または改訂管理における単純な人為的ミス）によって失われるため、再出現が発生することがあります。多くの場合、問題の修正は、最初に観察された狭いケースでは問題を修正しますが、ソフトウェアの寿命にわたって発生する可能性のあるより一般的なケースでは修正しないという点で「脆弱」です。多くの場合、ある領域の問題を修正すると、別の領域でソフトウェアのバグが発生します。最後に、いくつかの機能が再設計されると、その機能の元の実装で行われたのと同じ間違いのいくつかが再設計で行われた場合がよくあります。 アクションとフィルターのグローバルな性質により、クライアントが要求する機能を追加するにつれて複雑さが増し始め、特にWP_Queryデータベースへの呼び出しを頻繁に使用してデータベースを頻繁に更新する場合、複雑なプラグインを安定させるのが難しくなります。 私の考えでは、一連の「テストケース」を使用して回帰テストを設定し、「テストスイート」を構成します。概念的には、HTTP GETリクエストのHTML出力をテストするのはそれほど難しくありません。ただし、管理コンソール経由でログインしたり、jQueryの相互作用をテストしたりするときにテストする必要がある場合は、少し複雑になります。 ここでベストプラクティスを収集できることを期待して、これをコミュニティWikiとして設定していますが、他のWordPressの専門家が使用している場合は、プロセスを聞くのが本当に心配です。