Он не знает за авторизацию, он грузит данные из redux State, в которых может быть либо возвращенные данные с сервера, либо ошибка, либо нет аутентификации.

vintage Oct 28 2019 at 06:26

Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}

Как вы это читаете? У меня глаза вытекают при попытке распарсить.

ggo Oct 28 2019 at 06:38

Тут либо выбирать, что важнее, читаемый отчет о тестировании, или названия функций.

Либо использовать

@Unroll

vintage Oct 28 2019 at 06:44

читаемый отчет о тестировании

А его кто-то реально читает?

ggo Oct 28 2019 at 07:40

Зависит от контекста.
Если тест написан исходя из цели: управление качеством с минимальными затратами, то тесты будут регулярно падать, и понятное сообщение об ошибке (понятное широкому кругу лиц) упрощает восстановление.

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

vintage Oct 28 2019 at 09:49

Речь не про сообщения об ошибках, а именно об отчётах с листингом всех успешных тестов.

ggo Oct 28 2019 at 15:21

Экий вы затейник ;), листинг всех успешных тестов читать…
Даже не знаю что сказать… ;)

poxvuibr Oct 28 2019 at 10:32

Либо использовать Junit5 аннотацию @DisplayName

rudnevr Oct 28 2019 at 19:14

Да, это хорошая опция, если проект позволяет

vintage Oct 28 2019 at 06:30

Хорошие кандидаты на название компонента могут содержать название паттерна: Validator, Strategy, Builder, Transformer, Controller и тп. Или название события: Submitter, Login, ReadonlyOrderView и тп. Т.е. в зависимости от названия компонента должны быть определены и входные и выходные значения главной функции класса. Плохие названия: слишком абстрактные (Service,Component,Helper,Utility) и двойные (ValidatorAndRenderer).

А Validator, Builder и тд не абстрактные значит? Как понять какие абстрактные, а какие нет?

rudnevr Oct 28 2019 at 14:23

OrderValidator имеет метод validate и возвращает либо boolean, либо validationresult с ошибками. OrderBuilder имеет метод Build и возвращает Order. OrderService — непонятно что делает. Вот что я имею ввиду

vintage Oct 28 2019 at 15:23

OrderService имеет метод order и возвращает boolean. ButtonComponent имеет метод render и возвращает DOM. MultiplyHelper имеет метод multiply и возвращает number.

rudnevr Oct 28 2019 at 19:13

OrderService имеет метод order — то ниоткуда не следует. Я бы предположил, что он имеет методы CRUD для entity Order, но нет необходимости гадать.
ButtonComponent норм, но component не особо добавляет смысла, разве что в контексте фреймворка какого-то. MultiplyHelper is effectively Multiplier.

vintage Oct 28 2019 at 19:46

А откуда следует, что OrderValidator имеет метод validate, а не семейство методов visit_* для анализа AST?

ButtonComponent, ButtonState, ButtonTemplate, ButtonInterface… LogComponent, PageComponent, BookComponent...

MultiplyHelper, MultiplyToken, MultiplyNode, MultiplyHotkey, MultiplyIcon...

rudnevr Oct 28 2019 at 21:05

Это, вероятно, следует из контекста. Вряд ли в одном проекте сидит и AST парсер, и CRUD операции для сущности.
В остальном вы перечислили POJOs, которые возвращаются из методов, а не тестируемые классы. Какой метод у Icon?