Schreiben von Testfällen für ein WordPress-Plugin mit Übersetzungen

Was ist mein ziel

Ich freue mich darauf, Testfälle für die verfügbaren Übersetzungen eines WordPress-Plugins zu schreiben.

Mein Ansatz:

Ich habe WordPress mit VVV eingerichtet und meine Testsuite enthält PHPUnit und WP-CLI .

Um die Übersetzungen zu testen (zu bestätigen), überprüfe ich, ob die .moDatei der Sprache vorhanden ist oder nicht.

/**
 * 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' );
}

Wo stecke ich fest?

Ist dies der richtige Ansatz, um translationsein WordPress-Plugin zu testen ? Wenn nicht, schlagen Sie bitte Alternativen vor.

Wenn Sie nur testen möchten, ob die Übersetzungsdateien vorhanden sind, ist dies wahrscheinlich der einfachste Ansatz, da Sie PHPUnit wahrscheinlich bereits verwenden, um Unit- / Integrationstests für den Plugin-Code auszuführen.

Nur zu überprüfen, ob die Dateien vorhanden sind, sagt Ihnen jedoch nicht viel. Es sagt Ihnen nicht, ob diese Sprachen tatsächlich vollständig übersetzt sind oder ob diese Dateien von WordPress ordnungsgemäß geladen werden.

Die Frage, die Sie sich stellen müssen, lautet also: "Warum teste ich das?" Wenn Sie nur sicherstellen möchten, dass Sie nicht versehentlich eine Übersetzungsdatei auslassen, sollten Ihre Tests das tun, was Sie benötigen. Wenn Sie tatsächlich sicherstellen möchten, dass Sie vollständige Übersetzungen für jede Sprache haben und diese tatsächlich funktionieren, ist das eine ganz andere Geschichte.

Testen des Ladens von Übersetzungen

Um zu überprüfen, ob jede Übersetzungsdatei von WordPress ordnungsgemäß geladen werden kann, könnten Sie wahrscheinlich einen PHPUnit-Test erstellen, mit dem die Dateien geladen werden load_plugin_textdomain(), und überprüfen, ob sie zurückgegeben werden true, was darauf hinweist, dass die Textdomäne ordnungsgemäß geladen werden kann. Sie müssen sich wahrscheinlich in den plugin_localeFilter einbinden, um jedes Gebietsschema zu überprüfen, das mit Ihrem Plugin geliefert wird.

Vollständigkeit prüfen

Das würde Ihnen jedoch immer noch nicht sagen, wie viele der Zeichenfolgen tatsächlich in diese Sprache übersetzt wurden, wie viele unscharf sind usw. Wenn Sie überprüfen möchten, ob jede Übersetzung zu mindestens xx% vollständig ist, möchten Sie wahrscheinlich verwenden ein anderes Tool als PHPUnit dafür.

Aussehen testen

Sie können auch weiter gehen und überprüfen, ob die Zeichenfolgen in jeder Übersetzung tatsächlich korrekt in der Plugin-Benutzeroberfläche angezeigt werden. Manchmal ist eine Zeichenfolge in einer Übersetzung viel länger als in der Originalsprache, und dies kann dazu führen, dass der dafür vorgesehene Bereich überläuft. Um dies zu überprüfen, müssten Sie so etwas wie Codeception- Akzeptanztests verwenden.

Fazit

Ob die Tests, die Sie haben, der richtige Ansatz für Sie sind, hängt also davon ab, was Sie testen möchten. Persönlich habe ich keine Tests für die Übersetzungen meiner Plugins, obwohl mich der letzte Teil über das Überprüfen der Benutzeroberfläche fasziniert hat. Nur zu überprüfen, ob die Übersetzungen vorhanden sind, wie Sie es jetzt tun, scheint mir keinen großen Nutzen zu bringen. Es ist eine Prüfung, die nur so gut ist wie Ihre Liste der Übersetzungsdateien, nach denen Sie suchen. Und in einem gewissen Sinne ist es nicht wirklich testen alles, nur macht Sie sicher , dass es da ist. Dies könnte in einem Build-Skript anstelle von PHPUnit durchgeführt werden. Überprüfen , dass die Übersetzungen können tatsächlich geladen werden mit Wordpress tutIMO profitieren, weil es tatsächlich testet, dass sie nicht beschädigt sind. Und natürlich wird geprüft, ob sie gleichzeitig existieren. Also würde ich wahrscheinlich Ihre Tests erweitern, um das auch zu überprüfen.

Bearbeiten

In einem ähnlichen Zusammenhang könnten Sie auch in Betracht ziehen, Rechtschreibfehler in Ihrem Haupt-POT (und vermutlich auch in Übersetzungen) zu testen. Es ist leicht für diese, unter das Radar zu schlüpfen. Wahrscheinlich sind Shell-Skripte verfügbar, die dies tun könnten.