Телеграмм чат группы symfony

Если новый функционал добавляется модификацией методов, то это явное нарушение OCP. Хотите так делать - возитесь с тестами: изменили класс - очевидно, что надо менять тесты, его проверяющие.

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

источник

10:04пожаловаться #3

T🐜

The Ant 🐜 in symfony

Dmitry

я бы поглядел на регулярку которая найдет все создания инстансов и добавит туда мок, создав его выше :)

Так?
find:

new Foo(([\w+]), ([\d+]));

replace:

$bar = $this->createMock(Bar::class);\n
new Foo($1,  $bar, $2);

прям в идешке

источник

10:05пожаловаться #4

D

Dmitry in symfony

есть у вас RequestHandler
добавили галочку
RequestHandlerWithOption
добавили поле
RequestHandlerWithOptionWithField и тд

источник

10:05пожаловаться #5

IG

Ivan Grigoriev in symfony

Dmitry

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

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

источник

10:07пожаловаться #6

D

Dmitry in symfony

Ivan Grigoriev

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

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

👤U

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

Вот да. Монолиты не нужны.

источник

10:14пожаловаться #8

👤U

👤 User in symfony

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

источник

10:15пожаловаться #9

IG

Ivan Grigoriev in symfony

Dmitry

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

Но со старыми возиться не надо, так как старый код не менялся.

источник

10:15пожаловаться #10

👤U

👤 User in symfony

Надо смотреть как сохрани имя. Сохрани одну соц сеть. Поуправляй аватаркой.

источник

10:15пожаловаться #11

👤U

👤 User in symfony

А godclass который рулит ими всеми это самостоятельный выстрел себе в ногу.

источник

10:20пожаловаться #12

D

Dmitry in symfony

👤 User

Надо смотреть как сохрани имя. Сохрани одну соц сеть. Поуправляй аватаркой.

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

источник

10:46пожаловаться #13

👤U

👤 User in symfony

Так а зачем делать ультимативный тест?

источник

10:46пожаловаться #14

👤U

👤 User in symfony

Обычно короткий тест проверяет короткий метод.

источник

10:47пожаловаться #15

👤U

👤 User in symfony

Вот вам более плохой пример. Досталась мне в наследство функция оформления заказа на 1к строк. Без подметодов. Если бы я собрался их тестировать - засомневался бы в своей адекватности.

источник

10:48пожаловаться #16

👤U

👤 User in symfony

Разбили монолит на кучку методов и их затестировали. Если все части одной логики работают нормально, почему их суммарный результат должен не сработать?

источник

10:49пожаловаться #17

D

Dmitry in symfony

👤 User

Так а зачем делать ультимативный тест?

Ну вам нужен тест на каждый вызов другой функции чтобы понимать что ваша трестируемая адекватно реагирует на ответы.

источник

10:50пожаловаться #18

IG

Ivan Grigoriev in symfony

👤 User

Разбили монолит на кучку методов и их затестировали. Если все части одной логики работают нормально, почему их суммарный результат должен не сработать?

Поддерживаю.
Функция на 1к срок будет иметь зашкаливающую цикломатическую сложность. Т.е. количество тестов на неё должно быть соответствующее количество.

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

источник

10:53пожаловаться #19

D

Dmitry in symfony

Ivan Grigoriev

Поддерживаю.
Функция на 1к срок будет иметь зашкаливающую цикломатическую сложность. Т.е. количество тестов на неё должно быть соответствующее количество.

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

Вряд ли. По количеству тестов будет тоже самое. Вы ведь просто выделите куски в отдельные классы или приватные методы. Из протестируете.
Но сумма тестов отдельных модулей не гарантирует корректной работы кода где эти модули используются. Так что тестов даже станет больше.
Но будет удобнее. Да.

источник

10:59пожаловаться #20