твой родной

далее

аналитики

у тебя были проекты где бизнес использовал непонятные для тебя термины?

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

приемочный тесты разделять на куски не стоит (отдельно бэк отдельно фронт) тестировать надо целиком

Это долго и дорого

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

Можро сделать быстрее и дешевле

ну и естественно за Unit тесты

приемочный тесты разделять на куски не стоит (отдельно бэк отдельно фронт) тестировать надо целиком

так это ж ты разделяешь) приемочные тесты должны тестить логику

и только ее

иногда для этого надо зайти с UI

чаще - не надо

ну и 80% от твоей сюиты тестов должны составлять юниты)

как на бэке так и на фронте

я просто выразил имхо

а мы не согласились)

ну ок живите с этим

:D

потому что твое имхо обуславливается отсутствием работы с BDD)

возможно

но для каждой функциональности у меня нет времени писать юнит тесты, функциональные тесты, приемочные тесты и все это помноженное минимум на 2 (backend frontend)

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

тесты не всегда нужны

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

тесты не всегда нужны

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

http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/

хорошая статья

да мне тоже нравится, я вечно пишу гавнотесты там где они не нужны

цель BDD - Behaviour Driven Development - устранить стоимость перевода требований от языка бизнес на язык понятный техникал пипл

?

Тема тестов в этом чате всегда на несколько часов заводится :)

https://wwphp-fb.github.io/faq/

Вы даете интерфейсам суффикс Interface? Если да, то зачем?

потому что так положено!

Вы даете интерфейсам суффикс Interface? Если да, то зачем?

чтоб проще было саджестом выбирать + в дереве файлов сразу наглядно

тогда логичнее префикс типа I

ну и так больше нравится чем тот же подход из c# аля с префиклос Ай))

не успел написать

Вы даете интерфейсам суффикс Interface? Если да, то зачем?

Нет

Считаю это плохой практикой

почему?

тогда логичнее префикс типа I

это подход си, шарпа, мож еще кого, лично мне не очень по душе

Вот я тоже не понимаю, зачем оно

Потому что пользователю типа все равно интерфейс там или класс

тогда еще вопрос где вы храните интерфейсы в папке с реализациями или в отделньой аля Contracts

Почему тогда не называть FooClass и BarTrait

Трейты я тоже имею Трейт

тогда еще вопрос где вы храните интерфейсы в папке с реализациями или в отделньой аля Contracts

в папке с модулем

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

вы контроллеры как называете ? UserController?

а Сервисы ? UserService?

а Сервисы ? UserService?

Нет

или просто и там и там User | User

Это тоже плохо

а Сервисы ? UserService?

нет

ок =) как хорошо?

Controller\User

UserCreateService?

UserRegistration

а слово сервис вообще стараюсь не использовать

UserAuthorization

оно такое же бесполезное как Data или Info

ну по факту если они встретятся в 1м месте модель ,контроллер и тд придется все равно алиасы вешать

в той же симфе все контроллеры с префиксом контроллер

оно такое же бесполезное как Data или Info

Или модель

ERROR: S client not available

в той же симфе все контроллеры с префиксом контроллер

+

в той же симфе все контроллеры с префиксом контроллер

Постфиксом

ну да

вот вопрос - зачем

не важно)

зачем ну для наглядности =)

переменные тоже можно называть супер короткими , а можно нет =)

строгих правил вроде нет

вот вопрос - зачем

Снижение порога вхождения

Сервис Insight от Sensiolabs говорит, что надо давать этот сраный суффикс, я не вдупляю, нафига

ну в принципе согласен, дурость. так как не могут у тебя в Controller лежать НЕ контроллеры.

Снижение порога вхождения

чтоб не плодить алиасы из серии Controller/User as UserController

ну и тд

че тогда классы не называеть FooClass

ну в принципе согласен, дурость. так как не могут у тебя в Controller лежать НЕ контроллеры.

трейты могут или еще что

чтоб не плодить алиасы из серии Controller/User as UserController

Зачем?

че тогда классы не называеть FooClass

потому что Контролелры и тд это тоже классы

а что там трейты забыли?

Можно кейс, где это надо?

а что там трейты забыли?

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

че тогда классы не называеть FooClass

а FooInterface норм?

а FooInterface норм?

Нет

а FooInterface норм?

нет

Можно кейс, где это надо?

алиас? писла выше если классы с одним именем встретятся в 1м месте

нет

значит в psr не нормальные чуваки, вам видней

алиас? писла выше если классы с одним именем встретятся в 1м месте

Каким образом?

нет

так где лежат все интерфейсы у вас?

Не понимаю как так может случиться

ыот нормальное название интерфейса http://php.net/manual/en/class.jsonserializable.php

https://github.com/php-fig/log/blob/master/Psr/Log/LoggerInterface.php а это говно код ?

Контроллер в общем-то более-менее описывает обязанность класса

Не понимаю как так может случиться

class Controller\User { method (Model\User $user)}