Как мне процитировать работу с 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.