⚡ Kotobotov ⚡

дополнительно шифровать токен достаточно бессмысленная вещь - тк он уже представляет из себя зашифрованные данные.
Если требуется бОльшая безопасность у токена записывают короткое время жизни и требуют регулярно его обновлять (например каждый час), используя еще один токен)

много идеологических вопросов, что именно и зачем тестируете.
несколько уровней тестирования, обычно при ТДД разработке требуется быстрая обратная связь с тестами, и тестируют исключительно ту функциональность которую разрабатывают, без тестирование зависимостей в виде баз данных и тд, для этого используют разного рода заглушки (в виде мокапа).
тоесть базу данных вообще не используют.
В конце разработки, все равно прогоняются "интеграционные" тесты, по всему сервису, чтоб посмотреть работу сервиса в целом, включая все его части, тогда используется максимально идентичное окружение, что и как на продакшене, по возможности даже используя примерно такую-же БД что и на продакшене. База данных в памяти уже не соответствует этому требованию, может случится так, что например разница в задержках между тем как отрабатывало в памяти и как отрабатывает в реальности будет сильно отличатся, и приведет к неожиданному поведению.
ну и да на каждый такой интеграционный тест базу заново перезаписывают и заполняют темеже самыми данными что и ранее (мы же обычно в тестах проверяем соответствие исходным данным, потом проверяем например изменение этих данных, поэтому без отката этих данных назад, повторить теже самые тесты не получится)

у тебя задача передать токен на сервер -> это можно сделать через использования куки, но так не делают. ТК куки тырят, куки не универсальны и привязанны к определенному браузеру (куки не могут использовать приложения), и куча других проблем, особенно связанных с масштабированием.
Можно еще передавать токен вместе с каждым запросом в теле самого запроса ( пример: хттпс://адрес.ру/запрос?токен=токен)
но тогда токен будет сохраняться в истории браузера, и это тоже может привести к некоторым проблемам с безопасностью (например если ты перешел по ссылке, и человек на другом сервисе видет вместе со ссылкой источника перехода токен пользователя, это будет гиганский фэил)
вобщем наиболее подходящий способ -> передавать токен в каждом запросе вместе с хэдером, (тоесть передавать дополнительные параметры этого запроса минуя адресную строку)
почитай подробнее про http headers например https://www.tutorialspoint.com/http/http_header_fi...

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

токены эти могут передаваться на сервер в запросе в качестве параметра:
хттп://сайт.ру/данные.жсон?токен=ваш_токен

но такой способ считается плохим тк токены остаются в истории браузера например (ну и гет запросы обрезают длинну возможной ссылки)
наиболее подходящим способом считается передача токенов в заголовке запроса

подробнее о токенах советую посмотреть тут: https://jwt.io/introduction/