Понесло меня че-то

Я понял вашу позицию. :)

открыть страницу, сделать какие-то операции и дойти до определенного стейта, это время

ну и в моем случае еще долгий симфони стартап около 2х минут

Я сейчас скажу кое что, от чего у кого-то может и настроение испортится, но я использую ТДД, только для разных сервисов.

В остальных случаях - проще без них вести разработку а дописать потом

Это мое мнение

БДД - это вообще пиздец как по мне.

я говорю щас не за то что ТДД это хорошо или плохо, или когда писать тесты

я за то что код у тебя не зависит от фрейма

или я не прав?

Ну он не зависит :)

Но зависит все равно

Потому что у меня нет стадии "написан без фрейма"

даже контроллеры это такие же сервисы, которые зависят от интерфейсов и так же проверяются юнит тестами

правильность того что отрендерил твиг конечно не выйдет

но json проверить аж бегом

Контроллеры не должны тестироваться юниттестами :)

да и это нафиг не надо по сути

Это не может быть юнит тестом. Ты не юнит уже тестишь

Можно тестить их, если юзать Controller as a service

смотря что в твоем понятии юнит, а это может быть как и функция, так и класс, так и несколько классов в сборке, т.е модуль

Тогда можно замокать все.

Ну если ты не можешь замокать - ты уже тестируешь работу всего

в сборке

смотря что в твоем понятии юнит, а это может быть как и функция, так и класс, так и несколько классов в сборке, т.е модуль

тогда это функциональное тестирование

тогда это функциональное тестирование

если у тебя в изоляции несколько классов, то это еще вполне юнит тест, хотя тянет на интеграционный

Интеграционное скорее

Я ж говорю, это не может быть юнит тестом, если ты не замокал все зависимости

А если замокал, то в хорошем контроллере тестировать нечего

контроллер это такой же сервис с своими зависимостями, в чем проблема?

Да нет проблем :)

Но нечего там делать :)

Нечего тестировать

А если есть, то значит код не идеален уже :)

в контроллере может быть различная логика с редиректами, так что есть что тестить

в контроллере может быть различная логика с редиректами, так что есть что тестить

ну ты же просто можешь проверить ответ сервера, есть там редирект или нет. Не залезая в контроллер, или нет?

ну ты же просто можешь проверить ответ сервера, есть там редирект или нет. Не залезая в контроллер, или нет?

при этом тебе нужно поднять несколько баз, кролика скажем, настроить чтобы какой-нибудь пейпал не продовский юзался и тд

Мне тоже кажется, что end-to-end тестами контролеры проверять проще, через какой-нибудь Robot

Test env в докере-то забодяжить несложно, в принципе

при этом тебе нужно поднять несколько баз, кролика скажем, настроить чтобы какой-нибудь пейпал не продовский юзался и тд

такой вариант я не рассматривал )))

Мне тоже кажется, что end-to-end тестами контролеры проверять проще, через какой-нибудь Robot

когда приложение простое и достаточно фикстурок, то да, а сложный сетап это проблемнее

Мне тоже кажется, что end-to-end тестами контролеры проверять проще, через какой-нибудь Robot

по идее только так и надо, в контроллерах не должно быть чего-то такого что хочется по другому тестить

когда приложение простое и достаточно фикстурок, то да, а сложный сетап это проблемнее

мы сча про контроллеры или про что?

ну и скажем еще могут быть варианты с пулингом, когда ты обратился к серверу, тебя поставили в очередь и ты должен ходить и опрашивать пока обработают твой ответ, для этого должен крутится демон, а то и целая инфраструктура с демонами

ну и скажем еще могут быть варианты с пулингом, когда ты обратился к серверу, тебя поставили в очередь и ты должен ходить и опрашивать пока обработают твой ответ, для этого должен крутится демон, а то и целая инфраструктура с демонами

так это и есть e2e

В дев-окружении же работает это как-то, верно?

Значит и для теста поднять такое же получится

мы сча про контроллеры или про что?

да, но контроллер может быть связующим звеном в модулях

да, но контроллер может быть связующим звеном в модулях

поясни свою мысль

а хотя не, у меня всеравно вникать сейчас времени нет(

поясни свою мысль

если модули более-менее независимые, а тебе нужно дернуть данные из нескольких и потом вернуть это все клиенту. ты конечно можешь сделать для этого целый сервис, который будет дергать контроллер, но keep it simple

а с редиректами кроме как в контроллере где-то работать не очень хочется

если модули более-менее независимые, а тебе нужно дернуть данные из нескольких и потом вернуть это все клиенту. ты конечно можешь сделать для этого целый сервис, который будет дергать контроллер, но keep it simple

мы вообще что обсуждаем?

что за сервисы?

мы вообще что обсуждаем?

вообще обсуждали то что код не фреймворкозависимый

мы вообще что обсуждаем?

началось все с того, что симфонисты самые крутые пхпешники :)

а потом скатились в тестирование контроллеров

вообще обсуждали то что код не фреймворкозависимый

смотря какой

код который считает налоги не должен от фреймчорка зависеть

смотря какой

домен, сервисы и все что пишется через юнит тесты

с чего бы им зависеть от домена?

потому что у тебя инфраструктура протекла в домен?

вот это и пытаемся обьяснять людям

ERROR: S client not available

от фреймворка*

код который считает налоги не должен от фреймчорка зависеть

расскажи это Yii и ларавель разрабам

ну в ларавель вполне можно писать фреймворконезависимый код

а в yii - увы и ах нет

Но ты не берешь вреймворк, чтобы написать в нем только сервис по расчету налогов :)

точнее можно но толку тогда от yii

Ты написал его, а потом ты его используешь в фрейме. :)

А значит изучаешь фрейм, а значит становишься лучше. Или хуже.

Ты написал его, а потом ты его используешь в фрейме. :)

ну так у тебя не код от фрейма зависит, фрем потребляет твой код. Inversion of control и все такое

Дак я не об этом

дак аб чем ты?

ниочем?

А о том, что симфонисты - как прогеры - получше

А о том, что симфонисты - как прогеры - получше

ну это на метр выше дна в целом

те симфонисты которые берут симфони и херачат логику в контроллерах и сеттеры в сущностях не далеко от yii-ников ушли в плане синдрома утенка

и таких увы подавляющее большинство

ты еще не видел симфонистов которые логику в твиге херачат

не инструмент красит человека, а человек красит инструментом

Вопрос независимости от фреймворка желательно не перекуривать А то потом иногда обнаруживаешь самописные системы вместо общепринятых и всем известных депенденси

ты еще не видел симфонистов которые логику в твиге херачат

видел)

ну вот я об этом же, что профессионализм не зависит от фреймворка

ты еще не видел симфонистов которые логику в твиге херачат

О да. Было такое в тестовых заданиях.

Вопрос независимости от фреймворка желательно не перекуривать А то потом иногда обнаруживаешь самописные системы вместо общепринятых и всем известных депенденси

типа общепринятая подсистема пересчета скидок?)

давай мы все же научимся определять то о чем мы говорим, об домене или о инфраструктуре?

ну вот я об этом же, что профессионализм не зависит от фреймворка

нормальный разраб вряд ли для работы над средне-большим приложением возьмет Уии или вротпрессы

О да. Было такое в тестовых заданиях.

Как минимум валюты конвертировали и скидки считали в шаблонах.

нормальный разраб вряд ли для работы над средне-большим приложением возьмет Уии или вротпрессы

"человек который ничего больше не знает" = не нормальный человек?

нормальный разраб вряд ли для работы над средне-большим приложением возьмет Уии или вротпрессы

ну для маленького блога или магазина, могу запросто yii взять. Хотя скорее лару

симфонисты тоже вне зависимости от проекта будут симфони брать

"человек который ничего больше не знает" = не нормальный человек?

кругозор должен быть пошире, чтобы не выбирать между молотком и микроскопом