похоже, вы в прошлом использовали subversion ;) Это ведь одна из главных фич mercurial, мы работаем с локальным репозиторием, не боясь делать коммиты и не отвлекаясь на разрешение конфликтов, а когда чувствуем нужным, то делаем hg push
если разбирать конкретно этот пример, то вопрос. кто определяет список «нужных параметров»? я добавлю в шаблоне вызов неизвестной переменной. Сайт поломается, а тесты скажут всё OK. И наоборот, удалив переменную из шаблонов, тесты не сообщат о неиспользованной переменной. Т.е. все, о чем они будут сообщать нам, это о том, когда мы удалили/добавили переменные непосредственно в методе. Вот поэтому я считаю что useless.
Да, хранилище это тоже сервис, как и реквест, респонс, формы. Уже представляете сколько уйдет времени чтобы написать нужные моки?
Откуда я взял что автор считает его способ заменой функциональных тестов? Зачем тогда начинать статью про то как ужасны функциональные тесты и в идеальном мире ..?
Выше, про то, что такое ошибка я спросил не просто так. «контроллер рендерит другой шаблон, рендерит нужный, но несколько раз, или вообще его не рендерит. » — все это покажут функциональные тесты. testIndexAction is useless again.
PS: Symfony2 мне очень нравится и хочется чтобы фреймворк оставался таким же простым как сейчас, без этих «всё — сервисы». И нет, я считаю что unit tests конкретно для контроллеров useless.
возможно кто-то видит в этом смысле (я жду пока кто-нибудь объяснит его). я лишь не понимаю зачем говорить что «это» является заменой приемочных тестов, которые, по словам авторам, медленные и «вчерашний день».
автор показывает testIndexAction, в этом тесте есть мок (который показывает как работает indexAction внутри. И кстати, мелочь, но уже в таком простом примере конфигурация мока заняла 5 строк, в сложных проектах, когда в шаблоны передаются переменные, когда один метод возвращает разные форматы и т.п., этот мок займет экран). И завершается этот метод $this->assertEquals('success', $controller->indexAction()); который максимум протестировал что мок был сконфигрурирован правильно. И вы можете с некоторой уверенностью сказать что ваш indexAction работает без «ошибок»? Я — нет.
статья отвратительна.
Человек не понимает разницу между unit-тестированием и функциональным (приемочным) тестировании.
Он выдумал три недостатка приемочного тестирования. Контраргументы:
1. Конечно нужно запустить все ядро, ведь в этом и суть приемочного тестирование — тестируется работа всей системы в целом.
2. Конечно чувствительны. тесты пишутся с учетом спецификации, если эти изменения в дизайне не прописаны в спецификации — тесты должны это показать
3. Долго, но никто их и не запускает каждые 5 минут, а только, например, перед релизом.
Далее он предлагает использовать магический трюк в симфони чтобы сделать лишь что? протестировать внутренности метода контроллера! но зачем?? Это useless tests.
вот только не понятно, как покупателю доказывать потом что он вообще что-то оставлял в этой камере? или что зарплата была в рюкзачке в ней?
если для этого свидетели нужны, то их хрен найдешь. может табличка не так уже ужасна и заставляет лишний раз задуматься?
и получить отказ? т.к. у всех провайдеров есть такой пункт в договоре (цитата из договора макхоста):
4.5. Оператор, ни при каких обстоятельствах не несет ответственности перед Абонентом за косвенные убытки. Понятие “косвенные убытки” включает, но не ограничивается: потерю дохода, прибыли, ожидаемой экономии, деловой активности или репутации.
«притом не верная», да, мне такое объяснение не нравится: пример начинается непонятным названием класса ContentManaget; далее ему дается знание о кэше, о чем, по идеи, он не должен знать. С примером наследования все еще хуже. Вы добавили знание в объект о разделении прав в системе + при наследовании изменили интерфейс.
А вот хорошие книги, рекомендую почитать книгу Стива Макконнелла «Совершенный код». Подобные термины ооп там объясняются в первых же главах, некоторые на небольших примерах (в том числе и как не надо делать).
Да, хранилище это тоже сервис, как и реквест, респонс, формы. Уже представляете сколько уйдет времени чтобы написать нужные моки?
Откуда я взял что автор считает его способ заменой функциональных тестов? Зачем тогда начинать статью про то как ужасны функциональные тесты и в идеальном мире ..?
Выше, про то, что такое ошибка я спросил не просто так. «контроллер рендерит другой шаблон, рендерит нужный, но несколько раз, или вообще его не рендерит. » — все это покажут функциональные тесты. testIndexAction is useless again.
PS: Symfony2 мне очень нравится и хочется чтобы фреймворк оставался таким же простым как сейчас, без этих «всё — сервисы». И нет, я считаю что unit tests конкретно для контроллеров useless.
Человек не понимает разницу между unit-тестированием и функциональным (приемочным) тестировании.
Он выдумал три недостатка приемочного тестирования. Контраргументы:
1. Конечно нужно запустить все ядро, ведь в этом и суть приемочного тестирование — тестируется работа всей системы в целом.
2. Конечно чувствительны. тесты пишутся с учетом спецификации, если эти изменения в дизайне не прописаны в спецификации — тесты должны это показать
3. Долго, но никто их и не запускает каждые 5 минут, а только, например, перед релизом.
Далее он предлагает использовать магический трюк в симфони чтобы сделать лишь что? протестировать внутренности метода контроллера! но зачем?? Это useless tests.
если для этого свидетели нужны, то их хрен найдешь. может табличка не так уже ужасна и заставляет лишний раз задуматься?
4.5. Оператор, ни при каких обстоятельствах не несет ответственности перед Абонентом за косвенные убытки. Понятие “косвенные убытки” включает, но не ограничивается: потерю дохода, прибыли, ожидаемой экономии, деловой активности или репутации.
А вот хорошие книги, рекомендую почитать книгу Стива Макконнелла «Совершенный код». Подобные термины ооп там объясняются в первых же главах, некоторые на небольших примерах (в том числе и как не надо делать).