Як процитувати роботу з PHPUnit?

Я займаюся програмуванням веб-сайтів протягом 15 років та PHP протягом останніх 5 років. Я завжди писав суцільний код. ЯКЩО у мене є клієнт, який наполягає на 80% тестування коду. Оскільки клієнт ЗАДАЄ ПРАВО, я планую використовувати PHP_CodeSniffer, щоб переконатися, що мій код виглядає правильно, а PHPUnit зробити тестування мого пристрою. Я сподіваюся навчитися чомусь завдяки цьому досвіду.

Це правильні інструменти для використання? Скільки часу займає налаштування PHPUnit та написання додаткового коду? На написання веб-сторінок і самотестування мені знадобиться близько 8 тижнів, як я це робив у минулому. Якщо я додаю додаткові 4 дні (10%) для тестування одиниць (PHPUnit), чи достатньо? Думки? Пропозиції? Дякую.

В одному рядку: залежить, як ви працюєте. Я чесно думаю, що 10% - це занадто мало. Він повинен бути не менше 25%, якщо не 40%, якщо не 60%, якщо не більше.

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

Я буду говорити з того, що знаю. Я використовую TDD (Test-Driven Development) для більшості проектів. TDD в основному змушує вас писати тести перед фактичним кодом. Вони встановлюють набір критеріїв прийняття, яким повинен відповідати кінцевий продукт. Зазвичай ви витрачаєте від 50% до 70% свого часу на написання тестів, а решту на реалізацію коду, щоб вони пройшли.

Хоча це може здатися абсурдним та / або величезним, я можу запевнити, що це не так. Ось чому:

• Ви зможете розібратися, які найкращі архітектурні зразки використовувати під час написання тестів. Таким чином, коли ви почнете кодування, архітектура додатків зміниться мінімально (адже ми всі знаємо, наскільки дорого переробити архітектуру програми).
• Ви кодуєте лише те, щоб тести пройшли (тому зробивши кінцевий продукт прийнятним). Ви не витратите час на програмування непотрібних / поза сферою використання функцій.
• Маючи менше коду (тобто лише той код, який вам справді потрібен), він менш схильний до помилок. (Менше коду = менше помилок).
• Якщо ви помилитесь, і зробите це, знадобиться набагато менше часу, щоб з'ясувати, чому виникає проблема, і де проблема. Якщо тести написані належним чином, це означає, що одна помилка спричинить єдиний збій, а не ланцюгову реакцію. Таким чином ви зможете легко визначити джерело проблеми за лічені хвилини, якщо не секунди.
• Знадобиться набагато менше часу, щоб реально реалізувати код за допомогою одиничних тестів. Як тільки тест провалюється, ви знаєте, що щось не так. Щоб виправляти помилки, вам не потрібно робити взагалі назад з клієнтом.
• Зрештою, вам доведеться робити зворотній зв'язок з клієнтом, щоб виправити помилки, тому що нічого не може наздогнати 100% помилок. Однак ви можете легко зловити 95%, якщо не більше.

PHPUnit в значній мірі є фактичним інструментом для тестування модулів PHP, і це дуже добре. Я мало використовував PHP_CodeSniffer. Однак я думаю, що якщо ти працюєш один, то, певно, це не потрібно. У команді корисніше переконатися, що код виглядає однаково, незалежно від того, хто його кодував.

Підтримує вас за те, що ви з цього досвіду дізнаєтесь щось. Я впевнений, що станеш.

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

Білл Веннерс: У своїй книзі «Рефакторинг » ви говорите: «Якщо ви хочете зробити рефактор, головна умова - це тверді тести». Це означає, що якщо у вас немає тестів, ви не повинні робити рефактор?

Мартін Фаулер: Ви повинні думати про це як прогулянку по канаті без сітки. Якщо ви добре ходите по канаті, і він не так високий, то ви можете спробувати. Але якщо ви ніколи раніше не ходили по канаті, і це над водоспадом Ніагара, ви, мабуть, хочете гарної сітки.

^{Від http://www.artima.com/intv/refactorP.html}

Я писав PHP без тестування одиниць. Потім, через роки практики тестування одиниць на Java, я виявив, що не можу працювати над чимось набагато складнішим, ніж на одних сторінках PHP без тестування одиниць. Причина? Продуктивність . Без тестового опромінення я не міг би впевнено реагувати на рефактори - це означало, що або А) мені доведеться набагато більше руйнуватись і працювати над усім з самого початку, або Б) , мені доведеться мати справу з некрасивим, застарілим кодом.

Коли ви робите ставку, чи потрібно враховувати час для тестування? Так . Чи здається вам інтуїтивно зрозумілим, що це займе більше часу? Так, знову . Ймовірно, як і деякі інші відповіді приблизно оцінили, вам потрібно буде оцінити на 50-100% більше, ніж без одиничних тестів.

Однак! ...

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

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

Без тестування, ваші оцінки, швидше за все, це лунати. Про помилки, замовлення змін та переопределення все страшно точно оцінити. Тестування - це ключ до мінімізації впливу всіх трьох!

Непроста відповідь щодо того, скільки часу вам знадобиться.

Але як основне правило, якщо це короткий проект: я б сказав, що розробка разом з хорошим тестуванням одиниці займе 1,75-2 рази довше, ніж розробка без одиничного тестування. Для довших проектів може бути 25-30%?

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

Щодо PHPUnit .... Минув час, коли я його використав, моє враження, що він потужний, але, можливо, потребує ще трохи роботи, перш ніж його справді відшліфувати.

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

Поки що відповіді досить грунтовні, тому я просто додам один момент, який не висвітлюється: додатковий час через використання PHPUnit буде

1. вищий спочатку, оскільки ви це вивчаєте, і
2. скорочуйте нетестовий час розробки, оскільки ви отримаєте впевненість у цьому.

Моделі класів тестування модулів, які не стосуються презентації, досить прості. Ви пишете тест для кожного класу, і в цих тестових випадках ви можете безпосередньо інстанціювати і налаштувати об’єкт для тестування певного методу / функції. Після установки PHPUnit та запуску цих тестів ви зможете швидко працювати.

Тестування веб-сторінок блоку може бути більш складним. Якщо ви використовуєте Zend Framework, Symfony, Smarty або будь-який інший MVC-механізм, отримання PHPUnit, щоб грати з ними добре, може зайняти більше часу. Ми використовуємо Zend Framework, і я витратив чимало часу на створення базових класів для тестування контролерів та перегляду скриптів у відриві. Враховуючи розмір цього проекту, ви, мабуть, краще починати з цього ControllerTestCase.