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

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

Але якщо серйозно, це дійсно покращує якість, тому що, якщо з жодної іншої причини щось зламалося, ви можете побачити, який тест провалився або навіть якщо ви пропустили покриття в якійсь області.

Я не прихильник думки деяких, що ви повинні мати 100% покриття коду (і є причини, чому я так думаю), але я вважаю, що важливо мати якомога більше покриття коду, який не є прямим до WordPress.

Тестування коду в WordPress

Я не знаю, звучить це збентежено чи ні, але одна з пасток, у яку я потрапив на початку роботи з модульним тестуванням і WordPress, полягала в написанні тестів для основного коду WordPress.

Я все ще іноді це роблю (і ви можете запитати тих, з ким я працюю, чи це правда), хоча мені від цього стає краще.

Що стосується мене, сам WordPress можна розглядати як чорний ящик. Це основа, на якій живе ваша програма. Вже є тести ядра WordPress. Чи має бути більше? звичайно Чи достатньо того, що вони мають? З мого досвіду, так, але всі ми використовуємо різні підмножини зазначених функцій.

Я розумію ось що: кожного разу, коли ви працюєте над проектом, побудованим на WordPress; вам не потрібно писати тести на основі такого коду, як add_menu_pageабо wp_enqueue_script.

Ми знаємо, що ці функції працюють.

Натомість зосередьтеся на коді, який стосується вашого домену. Тобто зосередьтеся на коді, який пишете ви та ваша команда. Це буде сфера спеціальності, яка є унікальною в проекті, і це буде сфера, яка остаточно відповідатиме за вирішення певної проблеми.

Якщо ви прагнете отримати 100% покриття лише заради 100% покриття, тоді ви пишете модульні тести з правильної причини. Замість цього прагніть до найвищого ступеня охоплення коду, який достатньо перевіряє ваш код. Саме це забезпечить якість.