Quel est mon but?
Je suis impatient d'écrire des cas de test pour les traductions disponibles d'un plugin WordPress.
Mon approche:
J'ai installé WordPress avec VVV et ma suite de tests comprend PHPUnit et WP-CLI .
Afin de tester (assert) les traductions, je vérifie si le fichier .mo
de la langue existe ou non.
/**
* 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' );
}
Où je suis coincé?
Est-ce la bonne approche pour tester translations
pour un plugin WordPress? Si non, s'il vous plaît suggérer des alternatives.
Si tout ce que vous voulez tester, c'est que les fichiers de traduction existent, il s'agit probablement de l'approche la plus simple, car vous utiliserez probablement déjà PHPUnit pour exécuter des tests unitaires/d'intégration sur le code du plugin.
Cependant, vérifier si les fichiers existent ne vous en dit pas beaucoup. Il ne vous dit pas si ces langues sont réellement traduites, ou même si ces fichiers seront chargés correctement par WordPress.
La question que vous devez vous poser est la suivante: "Pourquoi est-ce que je teste cela?" Si vous voulez simplement vous assurer de ne pas omettre accidentellement un fichier de traduction, vos tests doivent alors répondre à vos besoins. Si vous voulez réellement vous assurer que vous avez des traductions complètes pour chaque langue et que celles-ci fonctionnent, c'est une histoire totalement différente.
Pour vérifier si chaque fichier de traduction peut être correctement chargé par WordPress, vous pouvez probablement créer un test PHPUnit qui charge les fichiers à l'aide de load_plugin_textdomain()
, et en vérifiant qu'il renvoie true
, ce qui indiquerait que le domaine texte peut être chargé correctement. Vous aurez probablement besoin de vous connecter à plugin_locale
filter pour vérifier chaque paramètre régional fourni avec votre plugin.
Cependant, cela ne vous dit toujours pas combien de chaînes ont été traduites dans cette langue, combien sont floues, etc. Si vous voulez vérifier que chaque traduction est au moins xx% terminée, vous voudrez probablement utiliser un outil autre que PHPUnit pour cela.
Vous pouvez également aller plus loin et vérifier que les chaînes de chaque traduction apparaissent correctement dans l'interface utilisateur du plugin. Parfois, une chaîne peut être beaucoup plus longue dans une traduction que dans la langue d'origine, ce qui peut entraîner un débordement de la zone qui lui est attribuée. Pour vérifier cela, vous devez utiliser quelque chose comme Codeception tests d'acceptation.
Donc, en conclusion, si les tests que vous avez sont la bonne approche pour vous dépend de ce que vous voulez tester. Personnellement, je n'ai pas de test pour les traductions de mes plugins, bien que cette dernière partie sur la vérification de l'interface utilisateur m'ait intriguée. Le simple fait de vérifier que les traductions existent, comme vous le faites maintenant, ne me semble pas très avantageux. C’est une vérification qui ne vaut que la liste des fichiers de traduction que vous recherchez. Et dans un sens, il ne fait pas test quoi que ce soit, mais s'assure simplement qu'il est là. Cela pourrait être effectué dans un script de construction plutôt que dans PHPUnit. Vérifier que les traductions peuvent effectivement être chargées par WordPress ne fournit un avantage à l’OMI, car elle vérifie en réalité qu’elles ne sont pas corrompues. Et bien sûr, cela teste leur existence en même temps. Donc, j'élargirais probablement vos tests pour vérifier cela aussi.
Sur une note connexe, vous pouvez également envisager de rechercher des erreurs d’orthographe dans votre POT principal (et dans les traductions également, je suppose). Celles-ci se glissent facilement sous le radar. Il existe probablement des scripts Shell pouvant le faire.