web-dev-qa-db-ja.com

翻訳があるWordPressプラグインのテストケースを書く

私の目的は何ですか?

私はWordPressプラグインの利用可能な翻訳のためのテストケースを書くことを楽しみにしています。

私のアプローチ:

_ vvv _ を使用してWordPressをセットアップし、テストスイートに PHPUnit および WP-CLI を含めます。

翻訳をテスト(表明)するために、言語の.moファイルが存在するかどうかをチェックしています。

/**
 * Test the translations.
 */
public function test_translations() {
    $this->assertFileExists( $this->object->path . 'lang/domain-name-de_DE.mo' );
    $this->assertFileExists( $this->object->path . 'lang/domain-name-lt_LT.mo' );
    $this->assertFileExists( $this->object->path . 'lang/domain-name-nl_NL.mo' );
}

どこで動けなくなるの?

これはWordPressプラグインのtranslationsをテストする正しいアプローチですか?そうでない場合は、代替案を提案してください。

7

テストしたいのが翻訳ファイルが存在することだけである場合、おそらくプラグインコードでユニット/統合テストを実行するために既にPHPUnitを使用しているため、これはおそらく最も簡単なアプローチです。

ただし、ファイルが存在するかどうかを確認するだけではあまりわかりません。これらの言語が実際に完全に翻訳されているかどうか、またはそれらのファイルがWordPressによって適切にロードされるかどうかはわかりません。

したがって、あなたが自問する必要がある質問は、「なぜ私はこれをテストするのですか?」です。誤って翻訳ファイルを削除しないようにしたい場合は、テストで必要なことを行う必要があります。各言語の完全な翻訳が実際にあり、これらが実際に機能することを実際に確認したい場合、それはまったく別の話です。

翻訳ロードのテスト

WordPressが各翻訳ファイルを適切にロードできるかどうかを確認するには、おそらく load_plugin_textdomain() を使用してファイルをロードするPHPUnitテストを作成し、trueを返すことを確認します。 textdomainが適切にロードされる可能性があります。プラグインに同梱されている各ロケールを確認するには、おそらく plugin_locale filter にフックする必要があります。

完全性のテスト

ただし、実際にその言語に翻訳された文字列の数、あいまいな文字列の数などはまだわかりません。各翻訳が少なくともxx%完了していることを確認する場合は、おそらくそのためのPHPUnit以外のツール。

外観のテスト

さらに進んで、各翻訳の文字列が実際にプラグインUIに正しく表示されることを確認することもできます。文字列は、元の言語よりも翻訳の方が長い場合があり、これにより、割り当てられた領域から文字列があふれることがあります。これを確認するには、 Codeception 受け入れテストのようなものを使用する必要があります。

結論

したがって、結論として、あなたが持っているテストがあなたにとって正しいアプローチであるかどうかは、あなたがテストしたいものに依存します。個人的には、プラグインの翻訳のテストは行っていませんが、UIの確認に関する最後の部分に興味をそそられました。あなたが今しているように、翻訳が存在することを確認するだけでは、多くの利点を提供するようには見えません。これは、チェック対象の翻訳ファイルのリストと同等のチェックです。そしてある意味では、実際にはtest何もテストせず、単に存在することを確認します。これは、PHPUnitではなくビルドスクリプトで実行できます。翻訳が実際にロードできることを確認するWordPressdoesは実際にテストするため、破損していません。そしてもちろん、それらが同時に存在することをテストします。そのため、おそらくテストを拡張して、それも確認します。

編集

関連する注意事項として、メインPOT(および翻訳でも)のスペルエラーのテストを検討することもできます。これらがレーダーの下に潜り込むのは簡単です。おそらく、これを実行できるシェルスクリプトが利用可能です。

4
J.D.