pro.jvm

04 Dec 2024 07:16

Или это можно делать только явно? (как в первом варианте)

pro.jvm

04 Dec 2024 07:09

Кайф когда документация устаревает и нужно ее поддерживать. И все это на совести разработчиков т.е. людей, которые не роботы, могут и не углядеть на код ревью и пустить дальше. Ни компилятор, ни линтер не подскажет когда плейн текст документация более не актуальна.
Пустили дальше неактуальную джавадоку (например, когда поменялся код в глубине а доку в самом верху изменить забыли) - получили скрытый незареганый тех долг.
Неактуальная дока может даже навредить, потому что в ней ложь. Это может быть еще хуже, чем отсутствие доки

pro.jvm

04 Dec 2024 00:49

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

pro.jvm

03 Dec 2024 23:40

Тут вообще не про библиотечный код тред развивается. Конечно у Либы есть Джавадоки, но на работе вы часто пишите джавадоки?

pro.jvm

03 Dec 2024 23:26

Кто то пишет джавадоки до сих пор?

pro.jvm

03 Dec 2024 23:25

Ну или у тебя сервис платный, например))

pro.jvm

03 Dec 2024 23:24

А зачем тест такой в котором не важна работа другого?

pro.jvm

03 Dec 2024 23:23

Хз, тест контроллера это как будто максимально близкий к клиенту, и максимально от него ожидается нормально работать. Интеграционный по хорошему

pro.jvm

03 Dec 2024 23:22

Или как контроллер тестится, все через интегрейшен 🤯

pro.jvm

03 Dec 2024 23:20

Зачем нужны моки сервисов то?

pro.jvm

03 Dec 2024 23:20

Ты наверно перепутал, я просто сказал, что моки нужны для тестов сервиса

pro.jvm

03 Dec 2024 23:16

Открой имплементацию, почитай javadoc. Все тоже самое

pro.jvm

03 Dec 2024 23:15

Для тестов как иначе 🤯

pro.jvm

03 Dec 2024 23:15

Эм, а кто мешает открыть тот же сервис impl, и глянуть?...

pro.jvm

03 Dec 2024 23:11

Не надо путать теплое с мягким

pro.jvm

04 Dec 2024 07:15

Можно ли как-то перегрузить конструктор класса-предка, чтобы был вариант без аргументов?

Сейчас вот так:

public class ExampleBlock extends Block {
    public ExampleBlock(Properties properties) {
        super(properties);
    }

    public ExampleBlock() {
        System.out.println("Overloaded constructor fired!");
    }
}

public class ExampleBlock extends Block {
    public ExampleBlock() {
        System.out.println("Overloaded constructor fired!");
    }
}

pro.jvm

04 Dec 2024 05:58

Ну на самом деле это не так устроено немного.

Сервис отвечает за имплементации бизнес метода

Контроллер за способ обращения к сервису

Один контроллер может обращаться к нескольким сервисам. Один сервис может использоваться в нескольких контроллерах.

pro.jvm

04 Dec 2024 00:49

В зависимости от соглашений на проекте

pro.jvm

03 Dec 2024 23:26

Сервисы не принадлежащие платформе(выходные взаимодействия) можно спокойно мокировать

pro.jvm

03 Dec 2024 23:26

Та вроде, может быть ситуация такая. Ты же не все бренчы покрываешь в тесте

pro.jvm

03 Dec 2024 23:24

И сколько он будет гоняться, если у тебя 100500 микросервисов, которые тоже надо, по-хорошему, поднять?

pro.jvm

03 Dec 2024 23:24

Ну или когда у тебя сервис вызывает другой сервис, но в тесте тебе не важна его работа. Как без мока сделать ?

pro.jvm

03 Dec 2024 23:23

Через прод на пользователях.

pro.jvm

03 Dec 2024 23:22

? Ну банально контроллер же можно оттестить. Там ты вызываешь сервис, туда мокаешь его. Это вроде популярный кейс не 🌚?

pro.jvm

03 Dec 2024 23:20

🌚, я на твоей стороне

pro.jvm

03 Dec 2024 23:20

Какое отношение тесты имеют к продакшн коду? В тестах у тебя будет библиотека, которая позаботится о моках. От программиста не требуется много усилий.

pro.jvm

03 Dec 2024 23:16

А смысл? Это завязка на детали реализации

pro.jvm

03 Dec 2024 23:15

А зачем сервис мокировать?

pro.jvm

03 Dec 2024 23:13

Контракт. Обычно Интерфейс помогает увидеть контракт сервиса и что сервис может делать

pro.jvm

03 Dec 2024 23:10

А мок чем не имплементация?