Чи ефективний процедурний код тестування одиниць?

У поточному проекті повноваження, які хочуть, щоб тестування одиниць було включено в наш цикл розробки, щоб уникнути постійної кількості помилок, які, здається, проникають у наш код. Проблема полягає в тому, що код спагетті становить 95% процедурних процедур, з якими я ніколи не робив одиничне тестування (весь мій досвід тестування одиниць був з кодом OOP)

Отже, моє запитання у двох словах: чи було б розумно продовжувати тестування одиниць з нашою поточною базою кодів чи запропонувати її відкласти до тих пір, поки додаток не буде переміщено до належної системи OOP?

PS: Хоча я намагався охарактеризувати це питання як мовний агностик, я відчуваю, що викладення відповідної програми використовує PHP та javascript допоможе надати більш конкретні відповіді, які могли б відповісти на це питання, оскільки з досвіду ця ситуація трапляється найбільше з такими програмами.

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

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

Зауважте, що вам доведеться:

• Виділіть ті функції, які вам доведеться перевірити, і ті, які вам не потрібно. В OOP це легко: приватні методи не повинні перевірятися, оскільки абоненти ніколи не зможуть отримати доступ до них безпосередньо. Швидше за все, у вашому процедурному кодексі деякі функції є такими, і вони не потребують тестів.

• Подумайте про глобальний масштаб . Проблема існує і в OOP, але якщо ви скажете, що вам доведеться перевірити код спагетті, є ймовірність того, що люди, які написали цей код, мають шкідливі звички, такі як занадто багато використовувати глобальний обсяг і робити якісь шалені речі, такі як зміни $_GETабо $_POSTмасиви всередині функції.

• Справа з кодом зовнішніх функцій. Це складніший випадок, але все ж можливий. Або ви перейдете require_onceна сторінку, щоб побачити, що відбувається, і зафіксуйте результат через ob_start/ob_get_clean , або ви зробите HTTP-запит з тестового набору та проаналізуйте відповідь шляхом аналізу HTML. Це насправді не тестування користувальницького інтерфейсу: тут вам не байдуже, чи з’являється кнопка на сторінці зліва чи справа, чи посилання великими червоними великими літерами або маленькими синіми. Що вам важливо - це знайти деякі елементи HTML через DOM та порівняти їх вміст із очікуваним.

• Перевірте коди відповідей . require_onceз буферизацією вихідних даних добре, але ви також повинні перевірити, як веб-додаток справляється з помилками. Наприклад, якщо очікуваний результат тесту 404 Не знайдено, ви повинні зробити HTTP-запит, щоб знати, що таке відповідь.

пропонуємо його відкласти, поки додаток не буде перенесено на належну систему ООП

Отримайте кілька автоматичних тестів на місці перед переходом на іншу платформу, а не після цього. Додайте подальші тести під час міграції, а не після цього. Якщо ці тести є "інтеграційними тестами" або одиничними тестами, ви повинні вирішити самостійно, але зазвичай ви можете використовувати улюблену рамку тесту xUnit для обох типів.

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

Те, як ці тести будуть реалізовані, буде відрізнятися між парадигмами та мовою. Найбільші речі, які вплинуть на вашу здатність робити тестування одиниць - це якість коду; менше, ніж використана парадигма. Пам'ятайте, тестування одиниці полягає в тому, щоб перевірити "одиницю" коду в самоті. Все, що впливає на вашу здатність виділяти "одиниці" коду, ускладнить тестування.

• використання глобалів
• побічні ефекти
• щільно пов'язаний код
• погано поєднаний код
• велика кількість умовних умов
• погано розроблені "одиниці"

Все це матиме більший вплив на складність тестування, ніж мовна парадигма.

Щоразу, коли у вас є ситуація, коли ви можете перевірити частини коду автоматично, тестування одиниць може бути ефективним. Отже, питання не може бути ефективним тестуванням процесуального коду, питання полягає в тому, що ЦЕ код може бути перевірений одиницею. Це буде залежати від того, скільки стан він читає і який стан він задає. В ідеалі відповідь на обидва - нуль, але якщо це не так, ви все одно можете перевірити.

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

Я не думаю, що можливо зробити справжні одиничні тести проти процесуального кодексу. Основна проблема полягає в тому, що кожна процедура, ймовірно, матиме багато залежностей, які неможливо усунути. У кращому випадку тести будуть інтеграційними тестами. Я робив подібну річ багато місяців тому з модулями VB6 та модулями VBA в MS Access.

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