Comments 11
А в итоге кода получается в несколько раз больше, чем может содержать модель, а что уж говорить про затраченное время…
Большую часть времени можно сэкономить инкапсулируя схожие тесты в классы, допустим проверка наличия лабелов у полей — ModelTest, и от него наследовать все остальные тесты для моделей. Да и при тестировании это может сэкономить уйму времени.
Это ключевой вопрос парадигмы TDD — если вы делаете блог — то возможно можно обойтись и «натурным» тестированием —
Если у вас десятки модулей — и много разработчиков, то после каждого коммита не натестируешься.
А написание тестов дисциплинирует — причем всех. ;-)
Если у вас десятки модулей — и много разработчиков, то после каждого коммита не натестируешься.
А написание тестов дисциплинирует — причем всех. ;-)
Во-первых, такие тесты очень простые и пишутся довольно быстро. Вообще, все тесты должны быть просты.
Во-вторых, время на дебаг с тех пор как я начал писать тесты заметно уменьшилось. А дебаг это обычно 50-80% времени работы на проектом.
В-третьих, я уверен в своём коде. Эта уверенность, поверьте, многого стоит. Я больше не «боюсь» своих проектов.
Во-вторых, время на дебаг с тех пор как я начал писать тесты заметно уменьшилось. А дебаг это обычно 50-80% времени работы на проектом.
В-третьих, я уверен в своём коде. Эта уверенность, поверьте, многого стоит. Я больше не «боюсь» своих проектов.
Все хорошо, только эти тесты полноценно назвать unit нельзя, т.к. они зависят от БД.
Как следствие:
1) тесты могут быть провалены из-за отсутствия коннекта к БД или отсутствия таблицы;
2) они долго выполняются, особенно если моделей много.
С другой стороны я не знаю как в рамках архитектуры Yii можно сделать простые и легко изменяемые unit-тесты моделей (например, в запросах, которые в конечном счете получаются могут появляться скобки, условия не обязательно дописываются в конец и более того, нельзя заранее с 100% уверенности предсказать, какой запрос получится, а значит TDD не получится).
Отмечу, что в официальной доке www.yiiframework.com/doc/guide/1.1/en/test.unit, эти тесты тоже называются unit.
Просьба автору внести это замечание в статью, т.к. это может вводить в заблуждение читающего.
Как следствие:
1) тесты могут быть провалены из-за отсутствия коннекта к БД или отсутствия таблицы;
2) они долго выполняются, особенно если моделей много.
С другой стороны я не знаю как в рамках архитектуры Yii можно сделать простые и легко изменяемые unit-тесты моделей (например, в запросах, которые в конечном счете получаются могут появляться скобки, условия не обязательно дописываются в конец и более того, нельзя заранее с 100% уверенности предсказать, какой запрос получится, а значит TDD не получится).
Отмечу, что в официальной доке www.yiiframework.com/doc/guide/1.1/en/test.unit, эти тесты тоже называются unit.
Просьба автору внести это замечание в статью, т.к. это может вводить в заблуждение читающего.
хорошая и подробная статья, спасибо. на ее основе освоил юнит тестирование в yii.
хотя у меня чисто unit тестирования не получается, модель использует api для валидации некоторых параметров и я не вижу разумного пути отвязать api (правила для одного параметра, допустим, могут меняться каждый день).
использую показатель code coverage %, но судя по структуре Yii, он оставляет желать лучшего. вся функция rules выглядит зеленой (phpstorm) даже после одного теста. соответственно вся модель зеленеет, что красиво для клиента, но неудобно для разработчика. как выкрутиться — пока еще не придумал.
хотя у меня чисто unit тестирования не получается, модель использует api для валидации некоторых параметров и я не вижу разумного пути отвязать api (правила для одного параметра, допустим, могут меняться каждый день).
использую показатель code coverage %, но судя по структуре Yii, он оставляет желать лучшего. вся функция rules выглядит зеленой (phpstorm) даже после одного теста. соответственно вся модель зеленеет, что красиво для клиента, но неудобно для разработчика. как выкрутиться — пока еще не придумал.
Так ли необходимо тестировать атрибуты? Для этого ведь есть validate(), разве что проверить разработчиков.
По моему метод generateString немного пахнет параноей:
А почему вы нигде не проверяете метод $category->save()?
Может быть такая ситуация, что вы или кто то напишет обработчик события на onBeforeSave(), с ошибкой при каких то условиях, но не напишет на него тест.
Вы запустите тесты — все гуд, все зеленые.
А самое главное — сохранять модель — не получится.
Ваши тесты подтверждают только то, что у модели есть правила, но не то проверяют может модель сохраниться или нет.
А вообще местами интересная. спасибо.
Может быть такая ситуация, что вы или кто то напишет обработчик события на onBeforeSave(), с ошибкой при каких то условиях, но не напишет на него тест.
Вы запустите тесты — все гуд, все зеленые.
А самое главное — сохранять модель — не получится.
Ваши тесты подтверждают только то, что у модели есть правила, но не то проверяют может модель сохраниться или нет.
А вообще местами интересная. спасибо.
У меня немного глупый вопрос, но я никак не могу понять, зачем писать столько методов, если можно все эти правила указать в одном методе testValidate()?
Проще будет найти, где отвалился тест — сомнительно, ведь для проверки модно указать сообщение.
Я не встречал ни одной реальной модели, которая содержала бы только один сценарий валидации. Получается, если несколько сценариев — количество подобных методов станет просто огромным и их будет неудобно поддерживать.
К тому же, как я понимаю, суть unit-теста проверить корректность работы конкретного метода т.е. один метод — один тестовый метод на него. Или я не прав?
Проще будет найти, где отвалился тест — сомнительно, ведь для проверки модно указать сообщение.
Я не встречал ни одной реальной модели, которая содержала бы только один сценарий валидации. Получается, если несколько сценариев — количество подобных методов станет просто огромным и их будет неудобно поддерживать.
К тому же, как я понимаю, суть unit-теста проверить корректность работы конкретного метода т.е. один метод — один тестовый метод на него. Или я не прав?
Sign up to leave a comment.
Юнит-тестирование моделей в Yii