Будут три виртуальные роута и один внутренний реальный контроллер

А какие юз кейсы будут Вот ты получил сущность альбом. Запросил у неё комментарии (просто дёрнул поле) и упал по памяти, потому что комментов миллион

Похоже, криво сформулировал. У меня уже есть сущность Comment (абстрактный класс), от которого наследуют Album/Photo/TextComment - комментарии для соответствующих сущностей альбома/фото/статьи. Разница между ними только в типе свойства Parent - всё остальное в абстрактном классе. Например: php class AlbumComment extends Comment { #[ORM\ManyToOne(inversedBy: 'comments')] #[ORM\JoinColumn(nullable: false)] private ?Album $parent = null; public function getParent(): ?Album { return $this->parent; } public function setParent(?Album $parent): static { $this->parent = $parent; return $this; } } Комментарии связаны со своими сущностями ManyToOne, как можно видеть. Выводятся они, соответственно, тривиально. Есть общий шаблон комментария, есть также общий шаблон формы для отправки комментария.

Или тебе нужно будет только вставлять коммент и удалять? А для того, что бы получить последние сущность не нужна?

Проблема у меня с отправкой/редактированием/удалением комментариев. У альбома/фото/статьи комментарии - это ведь фактически разные сущности. Соответственно в этих действиях создаются разные классы, редирект после обработки запроса делается на разные роуты и т.п. Вот для альбомов я это написал. А как теперь воткнуть это в контроллеры фото и статьи? Не копировать же код и заменять? Короче, проблема не в реализации. Думаю, что в моём недостатке знаний паттернов/практик. Короче как сделать понимаю, а как сделать грамотно - нет. Вот, хотел узнать.

Будут три виртуальные роута и один внутренний реальный контроллер

То есть я делаю контроллер типа CommentController, и в нём обрабатываю логику отправки/редактирования/удаления? И соответственно все действия с комментариями (кроме отображения в альбомах/фото/текстах) будут выполняться этим контроллером?

То есть я делаю контроллер типа CommentController, и в нём обрабатываю логику отправки/редактирования/удаления? И соответственно все действия с комментариями (кроме отображения в альбомах/фото/текстах) будут выполняться этим контроллером?

Ну все зависит от архитектуры приложения. Если у тебя точка входа логики контролёр, то да, как я выше написал. Если же контролёр это просто точка входа хттп формата и дальше он редиректит логику в сервис, то можно и три разных контроллера но один сервис

А можно совместить оба варианта

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

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

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

Юнит тесты апликейшен сервисов с кучей моков бесполезность и боль. А именно они инжектятся в контроллер

Боль когда у тебя 2000 тестов и все они выполняются пол часа, а потом ещё джс тесты которые ещё пол часа выполняются

Поэтому я предпочитаю юнит тесты

Боль когда у тебя 2000 тестов и все они выполняются пол часа, а потом ещё джс тесты которые ещё пол часа выполняются

Боль это когда после этого выкатываешь в прод и кладёшь его на пару часов, потому что тесты не поймали баг 😂

Это мега боль

Или нужно срочно хотфикс сделать а ты ждёшь пайплайн час

Боль когда у тебя 2000 тестов и все они выполняются пол часа, а потом ещё джс тесты которые ещё пол часа выполняются

36 секунд)

Или нужно срочно хотфикс сделать а ты ждёшь пайплайн час

Кстати для этого сделал skip test флаг

Или когда ты наконец дождался но кто-то уже смерджил в мастер и тебе нужно сделать рибейс и все сначала )

36 секунд)

Я не знаю точное количество тестов у нас но они реально минут двадцать выполняются

Поэтому я предпочитаю юнит тесты

Я не говорю про то что юниты не нужны, я говорю о том что { $entity= $this->repository->get() $this->calculator->action($entity) $this->em->flush() } Нечего именно тут юнитами тестировать

Бессмысленность тестирования белого ящика с кучей моков и почти 0 пользы

Что мы тут проверим? Что вызвался репозиторий, за ним калькулятор а за ним флаш? И что нам дает этот тест кроме хрупкости?

Профитней один тест на контроллер или на сервис но с БД, чтобы знать что у нас 200 а не 500.

А уже на калькулятор навесить юнитов

ТАк мы проверим что и БД впоряде, и система ок, и простые юниты с минимальным кол-вом моков. Основная проблема тестов - это их подготовка и поддержка. И чем сложнее тот или иной фактор, тем дольше их писать, тем чаще они забиваются, тем медленее идет разработка основных фич

Профитней один тест на контроллер или на сервис но с БД, чтобы знать что у нас 200 а не 500.

Ну не 1, хотяб валидные/невалмдные данные. Если фильтр есть парочку популярных.

тесты эндпоинтов и паратест в помощь

моки это ад

Ну не 1, хотяб валидные/невалмдные данные. Если фильтр есть парочку популярных.

Ну про 1, этот минимум, который позволит знать что система работает на положительном сценарии. А так да, можно увеличивать, зависит от предпочтений и целей. Все же тесты - код который мы пишем, поддерживаемый код и тех долг. Они не появляются из ниоткуда и не уходят в небытие.

Но с Юрием я тоже согласен, время тестов не надо исключать из факторов. Написать кучу мало полезных, но долгих тестов, которые ходят в БД, а потом ждать долгие ci - плохо и замедляет разработку.

Я не говорю про то что юниты не нужны, я говорю о том что { $entity= $this->repository->get() $this->calculator->action($entity) $this->em->flush() } Нечего именно тут юнитами тестировать

Ну хотябы то, что 1) ты правильным способом забрал энтити 2) ты точно вызвал экшон 3) ты точно вызвал flush Функциональный тест на ту же логику будет работать только если ты правильно его напишешь. Допустим мы забыли вызвать flush. Какие проверки это не покажут: a) проверка только респонса, так как сущность поменялась в памяти но не применилась к бд, но при этом смапилась в респонс b) проверка по фикстурам, так как не будет реального запроса в бд, вы просто достанете по памяти из identity map измененную сущность.

Ну хотябы то, что 1) ты правильным способом забрал энтити 2) ты точно вызвал экшон 3) ты точно вызвал flush Функциональный тест на ту же логику будет работать только если ты правильно его напишешь. Допустим мы забыли вызвать flush. Какие проверки это не покажут: a) проверка только респонса, так как сущность поменялась в памяти но не применилась к бд, но при этом смапилась в респонс b) проверка по фикстурам, так как не будет реального запроса в бд, вы просто достанете по памяти из identity map измененную сущность.

Это дублирование логики кода в тесте. Хрупкость теста, белый ящик. Сложный хрупкий тест на моках, не вижу смысла. Флаша может и вообще не быть, он будет например в мидлваре или еще где. Я считаю что надо минимум тестов, с минимум сложностей которые покроют максмум кейсов , а не 100% покрытие тестов и тестирования всего и вся. Это всё надо писать поддерживать, это всё $

Т.е. писать тест на то, что кто то удалил флаш в ходе разработки, я считаю излишество.

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

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

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

Совершенно верно. А вы можете бесконечно стремиться к 100% покрытию и отставать в разработке фичей

Т.е. писать тест на то, что кто то удалил флаш в ходе разработки, я считаю излишество.

Что собственно я и сделал, у меня был написан функциональный тест и я удалил флаш. Функциональный тест это не показал и я запорол фичу

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

Вы же понимаете что интеграционный и функциональные тесты дороги в обслуживании и мега хрупки. То есть вам по каждому чиху нужно будет лезть в огромную портянку из моков и проверок

Вы же понимаете что интеграционный и функциональные тесты дороги в обслуживании и мега хрупки. То есть вам по каждому чиху нужно будет лезть в огромную портянку из моков и проверок

Они как раз таки не хрупкие в отличие от юнита с кучей моков и белым ящиком

Вы же понимаете что интеграционный и функциональные тесты дороги в обслуживании и мега хрупки. То есть вам по каждому чиху нужно будет лезть в огромную портянку из моков и проверок

Да, равно наоборот 0 моков и черный ящик

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

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

Я не понимаю, зачем вы это рассказываете, если я выше это и написал

Они не хрупкие? У вас функциональные или интеграционные тесты связывают десятки или сотни классов. Это десятки или сотни причин для изменения. Вы пишите функциональные тесты без моков и фикстур? Реальные запросы чтоль в s3 там отправляете?

Они не хрупкие? У вас функциональные или интеграционные тесты связывают десятки или сотни классов. Это десятки или сотни причин для изменения. Вы пишите функциональные тесты без моков и фикстур? Реальные запросы чтоль в s3 там отправляете?

У меня интеграшки собирает контейнер в котором вместо s3 local storage, и практически нет подготовлительный фазы

Я не понимаю, зачем вы это рассказываете, если я выше это и написал

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

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

Вы просто пишите мне то, что я написал выше и рассказываете мне про мой код, который вы не видите и он не такой)))

Вы просто пишите мне то, что я написал выше и рассказываете мне про мой код, который вы не видите и он не такой)))

Так не рассказывайте нам как тестировать не ВАШ код, который не протестировать без моков, в котором сложная логика и комбинаторика.

Так не рассказывайте нам как тестировать не ВАШ код, который не протестировать без моков, в котором сложная логика и комбинаторика.

Ок

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

Вот я писал как тестить комбинаторику

Хочу говорить, не хочу слушать - об этом я и говорю про вас. Я же не спорю с вами, я с вами солидрен. Что комбинаторику надо тестить юнитами без моков, с отсуствием зависимости по максимуму

Поэтому я не понимаю, что вы мне пытаетесь рассказать, если я с вами не спорю и согласен

Чистые классы и функции с минимум зависимостей для сложной логики и юнит тестов

Много зависимостей и минимум логики - интеграционные

Я не говорю про то что юниты не нужны, я говорю о том что { $entity= $this->repository->get() $this->calculator->action($entity) $this->em->flush() } Нечего именно тут юнитами тестировать

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

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

Так то место где флаш - это место где куча зависимостей, и не то место где должна быть логика

А ну и насчёт скорости. 1 юнит тест гораздо быстрее чем функциональный с бд

Так то место где флаш - это место где куча зависимостей, и не то место где должна быть логика

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

И вот у вас есть логика Вы не написали тест Дальше кто-то добавил if и тест это не покажет

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

Пишите как вам удобно и тестируете что вам удобно. Я буду как мне удобно. Не вижу смысла писать дополнительный тест, на то что был кем то удален флаш.

Ураааа

Мы закончили эту духомотину

Мы закончили эту духомотину

Вы ее начали зачем то)))

борьба сама с собой)))

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

А вы хотите ограничить меня в высказывании своего мнения? Конечно же так всегда проще оставаться правым, когда остальные молчат

А вы хотите ограничить меня в высказывании своего мнения? Конечно же так всегда проще оставаться правым, когда остальные молчат

Почему, я согласил с Юрием и с другими участниками, вы же ворвались начали что то доказывать про какие то моки которых нет, при этом сказали что я душню. Много на себя берете Михаил

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

Простите, я был занят в этот момент. В следующий раз позвоните мне к начале очередного спора

Простите, я был занят в этот момент. В следующий раз позвоните мне к начале очередного спора

Да вы не очень то нужны были.Но ок

Почему, я согласил с Юрием и с другими участниками, вы же ворвались начали что то доказывать про какие то моки которых нет, при этом сказали что я душню. Много на себя берете Михаил

Нет, я говорил о том что у всех разные кейсы и громко заявлять о том, вот так тестировать не нужно очень странно. И в конце концов вы согласились, то есть мы пришли к консенсусу.

Та вы просто спорите что лучше интеграционные тесты или юнит тесты

Нет, я говорил о том что у всех разные кейсы и громко заявлять о том, вот так тестировать не нужно очень странно. И в конце концов вы согласились, то есть мы пришли к консенсусу.

Верно, по мне странно. Это мое мнение и оно не изменилось. Это не значит, что я говорю за всех или так теперь надо всем делать или не делать.

Что лучше яблоки или арбузы

Та вы просто спорите что лучше интеграционные тесты или юнит тесты

На самом деле нет, я даже не понимаю о чем мы спорим

По мне юнитами тестировать апликейшен сервисы лишняя работа с большой морокой в виде моков и с минимум профита. Но если вам там лучше и хотите максимальное покрытие - ок, ваше право.

Т.е. по мне лучше сделать 20 % возможных тестов, чтобы сделать 80 % полезности, и не добивать потом еще 80% тестов, чтобы покрыть оставшиеся 20%. Но опять же это имхо.

На самом деле нет, я даже не понимаю о чем мы спорим

Напомню, начали вот про этот ваш монолог. Дальше шло что-то про дублирование, я говорил что это не дублирование ну и так далее. А потом выяснилось что каждый останется при своём мнении, хотя если вы и не хотели это обсуждать то могли бы начать с этой фразы.

Напомню, начали вот про этот ваш монолог. Дальше шло что-то про дублирование, я говорил что это не дублирование ну и так далее. А потом выяснилось что каждый останется при своём мнении, хотя если вы и не хотели это обсуждать то могли бы начать с этой фразы.

Да и я продолжаю так считать, что это почти бесполезные тесты.

Сделать 3 мока, чтобы проверить что они вызывались последовательно. Не вижу смысла. Если видите - ок

Ну вот поэтому я и ворвался, так как это была провокационная фраза, а я падок на провокации.