✅ Новости WEB и WordPress, темы, плагины. Здесь мы делимся советами и лучшими решениями для веб-сайтов.

Краткая заметка о коде модульного тестирования в проектах WordPress

37

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

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

Я не разделяю мнение некоторых, что вы должны иметь 100% покрытие кода (и есть причины, почему я так думаю), но я действительно думаю, что важно иметь как можно больше покрытия кода, который не является напрямую в Вордпресс.

Тестирование кода в WordPress

Не знаю, звучит это запутанно или нет, но одной из ловушек, в которые я попал в начале работы с модульным тестированием и WordPress, было написание тестов для основного кода WordPress.

Я до сих пор иногда это делаю (и вы можете спросить у тех, с кем я работаю, правда ли это), хотя я поправляюсь в этом отношении.

Насколько я понимаю, сам WordPress можно рассматривать как черный ящик. Это основа, на которой живет ваше приложение. Уже есть тесты вокруг ядра WordPress. Должно ли быть больше? Конечно. Достаточно ли того, что у них есть? По моему опыту, да, но все мы используем разное подмножество указанных функций.

Суть в том, что я понимаю следующее: каждый раз, когда вы работаете над проектом, построенным на WordPress; вам не нужно писать тесты для кода типа add_menu_pageили wp_enqueue_script.

Мы знаем, что эти функции работают.

Вместо этого сосредоточьтесь на коде, специфичном для вашего домена. То есть сосредоточьтесь на коде, который пишете вы и ваша команда. Это будет область специализации, уникальная для проекта, и это будет область, которая в конечном итоге отвечает за решение данной проблемы.

Если вы стремитесь получить 100% охват только ради 100% охвата, то вы пишете модульные тесты не по правильной причине. Вместо этого стремитесь к наивысшей степени покрытия кода, которая достаточна для проверки вашего кода. Это то, что обеспечит качество.

Источник записи: tommcfarlin.com

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