issue 65 Поиск и получение подписок пользователя

[Dregid]

У меня небольшие сомнения были по поводу сервиса и репозитория. Сразу начну с последнего:

1. В репозитории в sql запросе, мы хотим получить всю информацию о подписках у пользователя, то есть, хотим получить все столбцы (всю строку) для каждой подписке пользователя. Нужно ли как то ограничить кол-во получаемой информации о подписке (то есть о пользователе на которого подписаны)?

2. В сервисе, полученный список мы сразу отправляем в место, откуда метод был вызван. То есть, он возвращает список с целыми моделями User, не приведенные в DTO. У меня уже была логика в голове, что если бы мне это нужно было делать — я бы циклом обошел весь список, и из каждого метода сделал бы UserDTO, и отправил это все новым списком, содержащий UserDTO объекты. Но мне это показалось жирным, т.к. человек в крайнем случае мог быть подписан на бешенное кол-во пользователей (лимон к примеру), и мне пришлось бы каждого пользователя в цикле переводить в DTO. Поэтому я решил обойтись сначала без него.

3. Теперь про тесты. Я все еще плохо в них разбираюсь, и иногда просто захожу в тупик — "А правильно ли я это делаю? А нужно ли это проверять? А вот эти два списка так нужно сравнивать? Вдруг их по другому нужно сравнивать. А как тогда?" Так что сделал так как понимаю нужным. Поэтому вопрос по поводу заглушек followee. Правильно ли то, что их вообще использую? Или нужно создавать на каждый элемент новый объект? Мне это тоже показалось жирным, поэтому создал один объект. И мне почему то кажется неправильной их проверка, чувство, как будто мне нужно сравнивать что то еще.

Вроде бы все...

[mighty-mhsl]

@Dregid

1. Вопрос хороший. В принципе прямо здесь это не нужно ограничивать, потому что мы в принципе получаем всю информацию о пользователях. Но вообще в теории для оптимизаций действительно не всегда нужно тащить все колонки из таблиц. Доставать нужно только то, что тебе именно нужно
2. Сервис и должен сущности смапить на DTO. Это нужно сделать. Контроллер должен получить дтошки и вернуть их из эндпоинта. Маппинг происходит именно в сервисе
3. Сравнивать в тестах нужно только результаты работы метода, который ты тестируешь, с ожидаемыми. Если тебе там нужно сравнивать несколько объектов, создаешь моки (заглушки) для всех необходимых объектов. Это всего лишь объекты в памяти, поэтому если ты их создашь условно 10 штук - это мелочи. Вот если бы миллион создавал - это была бы поблема

[Dregid]

Прочитал про Page — это бомба. Особенно для моей головы). Немного в этом разобраться помог пример с endpoint'ом для получения пользователей по нику, и то не с первого раза.

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