Спасибо, я это все знаю. Мне интересно, в каких типах тестов вы тогда предлагаете проверять, что аутентификация действительно работает верно с настоящими данными правильными/неправильными логинами/паролями. В чистом юнит-тесте это проверить нельзя, остается либо интеграционый либо функциональный. Я хочу выяснить немного другое, грань, где лучше писать юнит-тесты, а где интеграционные. Я думаю, что писать на каждый тестируемый метод и юнит тест и интеграционный тест это слишком затратно по времени. И зачастую является бесполезной тратой времени. Ниже пример.
Я могу замокать LoginForm::getUser() и сделать чтобы он сразу отдавал правильные данные. Но я думаю, что от такого юнит-теста пользы нет, потому что, если замокать LoginForm::getUser(), то в методе LoginForm::login() по-сути и нечего проверять, так как логика его работы крайне проста. Я думаю разработчики Yii исходили примерно из таких же соображений. И поэтому написали здесь интеграционный тест. Просто потому, что юнит-тест здесь не имеет смысла.
Я расчитывал получить ответ, примерно следующего содержания, что в некоторых ситуациях лучше написать на тестируемый метод интеграционный тест, а в некоторых юнит тест, предварительно оценив ситуацию. И то, что User::findByUsername() будет тестироваться два раза в разных тестах - это не критично и вполне нормальная практика.
Вы действительно видите какой-либо смысл писать на LoginForm::login() чистый юнит-тест ?
des1roer: фреймворк для создания веб-приложений от майкрософт. Больше ничего о нем сказать не могу, потому что читал туториал и писал свой говнокод на нем в далеком 2003, когда мне было 13 лет. Пол жизни уже прошло с того момента, помню только, что делал гостевую книгу :)
des1roer: Да. Тем же, чем и обычно. Пишут серверную логику, работают с базой данных. Вы просто на бекенде в контроллере не рендерите вьюху, а отдаете данные например в JSON формате.
des1roer: Нет, angular это не сахар над js. Да, это чистый фронтенд фреймворк. Он избавляет от прямой работы с DOM. Все изменения сделанные в модели (model), автоматически отображаются во вью (view) и наоборот. Благодяря этому, вы пишите только логику приложения. Эту логику легко покрыть юнит-тестами.
Если вы писали когда-либо с помощью библиотеки jQuery или на ванильном js, то должны понимать, что в итоге получается каша из DOM и собственно логики. Angular берет работу с DOM на себя, оставляя за вами только написание логики приложения.
Да php фреймворки умеют генерировать готовый html. Но суть то заключается в разделении зон ответственности. Чтобы всё было разложенно по полкам. Чтобы клиентская и серверная части могли разрабатываться независимо друг от друга. Чтобы фронтенд программист не вникал, как и что там работает на сервере, ему достаточно только знать, как запросить с этого сервера данные. И не более того. Ему не нужно знать о php вообще ничего. Тоже самое серверному программисту, совершенно фиолетово, какие там юзер-интерфейсы пишет фронтенд программист, он только знает, что ему нужно реализовать возможность работы с данными (get/post/put/delete) и идти пить пиво.
des1roer: Yii 2 из коробки предлагает возможность по созданию RESTful Api www.yiiframework.com/doc-2.0/guide-rest-quick-star... . Отличие в том, что RESTful сервер предоставляет исключительно данные, он не занимается генерацией html-кода. На AngularJS вы пишите клиент, который эти данные будет потреблять. Тем самым вы четко разделяете зоны ответственности.
Алексей Инклюдер: Так сделано в любом фреймворке, где одна точка входа в приложение index.php. Указывается правило, чтобы всё, что не является реальным файлом обрабатывалось index.php, а приложение уже само разруливает, что нужно вывалить пользователю в ответ на этот роут.
crows: вконтакте используют HTTP Streaming и это работает. Суть, с помощью XmlHttpRequest клиент делает запрос к веб-серверу, тот поднимает php скрипт с бесконечным циклом и проверкой на появление новых событий для клиента, как только событие наступило, данные отправляются клиенту, но соединение с веб-сервером не закрывается, а работает дальше. По истечению таймаута в 25 секунд соединение закрывается и открывается заново. Так работают например личные сообщения. Это одна из разновидностей Comet технологий.
Другой пример. Популярная браузерная игра Бойцовский клуб, там чат работает с помощью отправки ajax-запросов раз в 15 секунд и доставляет клиенту сообщения с сервера. В 2004-09 годах в пиках онлайн достигал 7к игроков. И даже такой самый простой подход работал и работает до сих пор.
На вскидку из comet технологий, можно сделать polling/long polling/http streaming и всё это делается с помощью объекта xhr ну или как в народе говорят ajax.
В качестве альтернативы комет-технологиям есть websocket-протокол, как раз для этих целей. Но с ним всё сложнее, написать свой нормально работающий и масштабируемый вебсокет сервер задача не из легких.
Алексей Ярошевич: Ваш оппонент о яндексе верно говорит, знакомый в яндексе работал питон девелопером, так и было 40 изначально, потом подняли до 60 тыс. руб.
myset 1 2 3 4 5
Первые три элемента были добавлены первым websocket сервером, последние два вторым сокет-сервером. Первый сокет-сервер упал. Как отдельному демону узнать, какие именно элементы нужно удалить из myset ?
В качестве лоад балансера, я хотел использовать nginx, чтобы проксировать websocket-траффик на различные сервера, с помощью round-robin.
Я могу замокать LoginForm::getUser() и сделать чтобы он сразу отдавал правильные данные. Но я думаю, что от такого юнит-теста пользы нет, потому что, если замокать LoginForm::getUser(), то в методе LoginForm::login() по-сути и нечего проверять, так как логика его работы крайне проста. Я думаю разработчики Yii исходили примерно из таких же соображений. И поэтому написали здесь интеграционный тест. Просто потому, что юнит-тест здесь не имеет смысла.
Я расчитывал получить ответ, примерно следующего содержания, что в некоторых ситуациях лучше написать на тестируемый метод интеграционный тест, а в некоторых юнит тест, предварительно оценив ситуацию. И то, что User::findByUsername() будет тестироваться два раза в разных тестах - это не критично и вполне нормальная практика.
Вы действительно видите какой-либо смысл писать на LoginForm::login() чистый юнит-тест ?