Написание тестовых примеров для плагина WordPress с переводами

Какова моя цель?

Я с нетерпением жду возможности написать тестовые примеры для доступных переводов плагина WordPress.

Мой подход:

У меня установлена ​​программа WordPress с использованием VVV, и мой набор тестов включает 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' ); } 

Где я застрял?

Правильно ли это подходит для тестирования translations для плагина WordPress? Если нет, предложите альтернативы.

Если все, что вы хотите проверить, это то, что файлы перевода существуют, то это, вероятно, самый простой подход, поскольку вы, вероятно, уже используете PHPUnit для запуска тестов unit / integration в коде плагина.

Тем не менее, просто проверка того, существуют ли файлы, мало говорит вам. Он не говорит вам, действительно ли эти языки полностью переведены или даже если эти файлы будут правильно загружены WordPress.

Поэтому вопрос, который вам нужно задать самому себе: «Почему я тестирую это?» Если вы просто хотите убедиться, что вы случайно не оставили файл перевода, ваши тесты должны делать то, что вам нужно. Если вы хотите убедиться, что у вас есть полный перевод для каждого языка, и что они действительно работают, это совсем другая история.

Тестирование загрузки перевода

Чтобы проверить, может ли каждый файл перевода правильно загружаться WordPress, вы, вероятно, могли бы создать тест PHPUnit, загружавший файлы с помощью load_plugin_textdomain() и проверку того, что он возвращает true , что указывает на правильную загрузку textdomain. Вероятно, вам нужно подключиться к фильтру plugin_locale чтобы проверить каждую локаль, которая поставляется вместе с вашим плагином.

Полнота тестирования

Тем не менее, это все равно не скажет вам, сколько строк было фактически переведено на этот язык, сколько нечетких и т. Д. Если вы хотите проверить, что каждый перевод не превышает xx%, вы, вероятно, захотите использовать инструмент, отличный от PHPUnit для этого.

Внешний вид тестирования

Вы также можете пойти дальше и проверить, что строки в каждом переводе действительно отображаются правильно в пользовательском интерфейсе плагина. Иногда строка может быть намного длиннее в переводе, чем на исходном языке, и это может привести к переполнению выделенной области. Чтобы проверить это, вам нужно использовать что-то вроде приемочных тестов Codeception .

Вывод

Итак, в заключение, зависит ли ваш тест от правильного подхода к тому, что вы хотите проверить. Лично у меня нет никаких тестов для переводов моих плагинов, хотя эта последняя часть о проверке пользовательского интерфейса меня заинтриговала. Просто проверяя, что переводы существуют, как вы сейчас это делаете, мне не кажется, что они приносят большую пользу. Это проверка, которая так же хороша, как и список файлов переводов, которые вы проверяете. И в каком-то смысле это ничего не проверяет , просто убедитесь, что оно есть. Это может быть выполнено в скрипте сборки, а не в PHPUnit. Проверка того, что переводы действительно могут быть загружены WordPress, действительно обеспечивает ИМО, потому что она фактически проверяет, что они не повреждены. И, конечно же, он проверяет, что они существуют одновременно. Поэтому я бы, вероятно, расширил ваши тесты, чтобы проверить это тоже.

редактировать

В соответствующей заметке вы также можете рассмотреть возможность тестирования любых орфографических ошибок в вашем основном POT (и, я думаю, в переводах тоже). Легко для них проскользнуть под радаром. Возможно, есть сценарии оболочки, которые могут это сделать.