Я занимаюсь веб-программированием в течение 15 лет и PHP последние 5 лет или около того. Я всегда писал солидный код. ОДНАКО, у меня есть клиент, который настаивает на 80% кода, тестируемого модулем. Поскольку клиент ВСЕГДА ПРАВ, я планирую использовать PHP_CodeSniffer, чтобы убедиться, что мой код выглядит правильно, и PHPUnit для выполнения моего модульного тестирования. Я надеюсь узнать что-то из этого опыта.
Это правильные инструменты для использования? Сколько времени уходит на настройку PHPUnit и написание дополнительного кода? Мне понадобится около 8 недель, чтобы написать веб-страницы и самопроверку, как я делал в прошлом. Если я добавлю 4 дня дополнительных (10%) для модульного тестирования (PHPUnit), этого достаточно? Мысли? Предложения? Спасибо.
Ответы:
В одной строке: это зависит от того, как вы работаете. Я честно думаю, что 10% это слишком мало. Это должно быть не менее 25%, если не 40%, если не 60%, если не больше.
Во-первых, я очень согласен с вашим клиентом там. Модульные тесты являются неотъемлемой частью надежного, простого в обслуживании и легко отлаживаемого продукта.
Я буду говорить из того, что я знаю. Я использую TDD (Test-Driven Development) для большинства проектов. TDD в основном заставляет вас писать тесты перед реальным кодом. Они устанавливают набор критериев приемлемости, которым должен соответствовать конечный продукт. Обычно вы тратите от 50% до 70% своего времени на написание тестов, а оставшуюся часть - на реализацию кода, который позволит им пройти.
Хотя это может показаться абсурдным и / или огромным, я могу заверить вас, что это не так. Вот почему:
PHPUnit - это практически инструмент де-факто для модульного тестирования PHP, и он очень хорош в этом. Я не использовал PHP_CodeSniffer много. Тем не менее, я думаю, что если вы работаете в одиночку, вам, вероятно, это не нужно. В команде более полезно убедиться, что код выглядит одинаково, независимо от того, кто его кодировал.
источник
Поддерживает вас за то, что вы научились чему-то на этом опыте. Я уверен ты будешь.
Первое, что вы должны усвоить, это то, что необходимость модульного тестирования не имеет ничего общего с тем, насколько вы опытны . Лучшим разработчиком станет также один из лучших юнит-тестеров:
С http://www.artima.com/intv/refactorP.html
Я писал PHP без юнит-тестирования. Затем, после нескольких лет практики модульного тестирования в Java, я обнаружил, что не могу работать над чем-то намного более сложным, чем отдельные страницы в PHP, без модульного тестирования. Причина? Производительность . Без модульного тестирования я не смог бы с уверенностью провести рефакторинг - это означало, что либо А) мне пришлось бы гораздо больше разрушать и работать над всем с самого начала, либо Б) , мне приходилось иметь дело с уродливым, унаследованным кодом.
Когда вы делаете ставку, нужно ли учитывать время для тестирования? Да . Кажется ли интуитивно понятным, что это займет больше времени? Да, опять . Вы, вероятно, как и некоторые другие приблизительные оценки, должны оценить на 50-100% больше, чем без модульных тестов.
Однако!...
И в результате ваши оценки будут более точными . Если вы будете взимать почасовую оплату, вы будете больше удивлять своих клиентов и сможете повышать ставки. Если вы будете платить фиксированную ставку, вы будете зарабатывать больше денег в час.
Без тестирования, ваши оценки, скорее всего, сумасшедшие. Ошибки, заказы на изменения и переопределения - все это ужасно для точной оценки. Тестирование является ключом к минимизации воздействия всех трех!
источник
Нет простого ответа относительно того, сколько времени это займет у вас.
Но в качестве основного правила, если это короткий проект: я бы сказал, что разработка вместе с хорошим модульным тестированием займет 1,75-2 раза больше, чем разработка без модульного тестирования. Для более длинных проектов может быть 25-30%?
Я предлагаю сделать модульные тесты, прежде чем писать свой код. Таким образом, создание лесов модульного тестирования фактически становится частью вашего процесса проектирования, и поэтому вам не следует думать, что вы теряете время на модульное тестирование, а скорее то, что создание модульного теста помогает вам спроектировать Отличный продукт и наличие этого теста после того, как вы его создали, облегчает вам уверенность в том, что он останется таким. Первое, что нужно для написания модульных тестов, прекрасно помогает сосредоточиться на реальных требованиях, дает нам четкий способ проверить, закончили ли мы (прохождение модульных тестов) и помогает нам «тестировать рано и часто тестировать».
Что касается PHPUnit .... Прошло довольно много времени с тех пор, как я его использовал, у меня сложилось впечатление, что он мощный, но, возможно, ему нужно еще немного поработать, прежде чем он действительно отработан.
Если есть одна вещь, о которой я хочу рассказать здесь: пожалуйста, не рассматривайте модульное тестирование как простую формальность в конце вашего проекта. Если это все, на мой взгляд, это ничего не стоит.
источник
Ответы до сих пор довольно подробны, поэтому я просто добавлю один не охваченный вопрос: дополнительное время за счет использования PHPUnit будет
Модульные классы тестирования моделей, которые не имеют отношения к представлению, довольно просты. Вы пишете тест для каждого класса, и в этих тестовых примерах вы можете непосредственно создать экземпляр и настроить объект для тестирования определенного метода / функции. Установив и запустив PHPUnit, вы сможете быстро запустить эти тесты.
Модульное тестирование веб-страниц может быть более сложным. Если вы используете Zend Framework, Symfony, Smarty или любой другой движок MVC, то для того, чтобы PHPUnit хорошо играл с ними, может потребоваться больше времени. Мы используем Zend Framework, и я потратил значительное количество времени на создание базовых классов для тестирования контроллеров и отдельного просмотра сценариев. Учитывая размер этого проекта, вам, вероятно, лучше начать с
ControllerTestCase
.источник