Как и обещал в прошлом посте выкладываю свое решение задания:

Задание:

🧪 В проекте с автотестами на Rest Assured:

— Прокиньте токен из @BeforeAll во все тесты.
— Сделайте это без статики.
— Сохраните архитектурную чистоту (SOLID, KISS).

🐈 GitHub: https://github.com/topsycreed/rest-assured-token
В решении используется Java, Gradle, JUnit 5, AssertJ, Rest Assured, Jackson, Allure, Lombok и Owner для чтения properties.

Тестировал решил API сценарий добавления товара в корзину для сайта https://www.ae.com/us/en — этот же сайт и его API используем на моем бесплатном курсе по автоматизации на Java в рамках курсового пет проекта.

Что было сделано:
1️⃣ Создан TokenManager - Хранит токены по ролям (GUEST, AUTH) в ThreadLocal<EnumMap<>>
Использует ленивую инициализацию computeIfAbsent Позволяет получить токен через TokenManager.getToken() или .getToken(UserRole)

2️⃣ Создано JUnit-расширение - GuestTokenExtension и заготовка для будущего AuthTokenExtension
В beforeAll() устанавливает роль (TokenManager.setCurrentRole(...)) И иницилизируется токен (TokenManager.getToken())

3️⃣ Контроллер (BagController) не знает о ролях
Просто вызывает TokenManager.getToken() — и получает нужный токен Роль уже была установлена расширением → нет дублирования

4️⃣ Отдельный контроллер для токенов (TokenClient)
Передаем авторизационный хедер из свойств, если нужно можно даже сделать секретными данными, для Guest общедоступная информация.

Почему решение архитектурно чистое:
• KISS - Простой TokenManager, один вызов в контроллере
• Single Responsibility Principle - TokenManager отвечает только за токены, контроллер — за API
• Open/Closed Principle - Добавить новую роль — легко (новое расширение)
• Dependency Inversion Principle - Контроллер не зависит напрямую от способа получения токена
• Без static в тестах - всё управление токеном — через @ExtendWith(...)

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