Skip to content

Latest commit

 

History

History
67 lines (58 loc) · 5.96 KB

AGENTS.md

File metadata and controls

67 lines (58 loc) · 5.96 KB

О тестируемом приложении

  1. Аутентификация
  • Тип: сессионная (Spring Security form login).
  • Логин-эндпоинт: POST /login. Тело формы: поля username и password (Content-Type: application/x-www-form-urlencoded). См. templates/login.html и SecurityConfigNoSSO.
  • После логина использовать cookie JSESSIONID. CSRF включён: CookieCsrfTokenRepository.withHttpOnlyFalse() и CsrfTokenRequestAttributeHandler().
    • Клиент читает cookie XSRF-TOKEN и передаёт его в заголовке X-XSRF-TOKEN на все state-changing запросы (POST/DELETE/…).
  • Basic Auth не настроен и не используется.
  1. Формат ошибок
  • Бизнес-валидации/конфликты возвращаются как 200 OK с телом ApiResponse.success=false и message с текстом ошибки. 4xx, как правило, не используются для таких случаев.
  • Структура ответа: { "success": false, "message": "…", "errCode": "…"? (опционально), "debugMessage": "…"? (опционально), "data": …? (опционально), "timestamp": "dd-MM-yyyy hh:mm:ss" }
  • Пример (дубликат пользователя): 200 OK { "success": false, "message": "Failure. User already exists." } Источник: UsersTeamsControllerService.addNewUser → TEAMS_ERR_110.
  1. Тестовые данные (teamId, tenantId, role)
  • Базовый tenantId: 101 (KwConstants.DEFAULT_TENANT_ID).
  • Дефолтные команды: INFRATEAM и STAGINGTEAM. Их teamId и tenantId лучше получить вызовом:
    • GET /getAllTeamsSU → массив TeamModelResponse { teamId, tenantId, teamname, … }.
  • Роли: получить динамически через GET /getRoles или /getRolesFromDb. В коде упоминаются как минимум USER и SUPERADMIN (KwConstants).
  • Сценарии:
    • «Успешное создание»: возьмите валидный teamId из /getAllTeamsSU и tenantId из этого же ответа (или 101), роль — существующую из /getRoles.
    • «Несуществующий teamId/tenantId»: подайте значения, которых нет в выборке (/getAllTeamsSU и /getTenants). Ожидайте ApiResponse.success=false с сообщением о проблеме (например, Team id cannot be empty/Failure. Team already exists. не про это — но типовой паттерн: notOk с текстом из KlawErrorMessages).
  1. Уникальность username
  • Уникальность проверяется глобально по инстансу, а не в границах tenantId: registerUser использует getAllUsersAllTenants(). addNewUser обрабатывает ошибки вставки и маппит на TEAMS_ERR_110.
  • Ответ при дубликате: 200 OK, { "success": false, "message": "Failure. User already exists." }.
  1. Верификация создания пользователя
  • Предпочтительно: GET /getUserDetails?userId={username}. userId — это username. Ответ: UserInfoModelResponse или null.
  • Альтернатива: GET /showUserList с параметрами teamId (опционально) и/или searchUserParam (подстрока username).
  1. Требования к паролю
  • Регулярное выражение (KwConstants.PASSWORD_REGEX): (?=.[a-z])(?=.[A-Z])(?=.\d)(?=.[\W_]).{8,}
  • Явная валидация по regex применяется на смене/сбросе пароля (/chPwd, /reset/password). На /addNewUser сервис шифрует пароль (bcrypt) при типе аутентификации "db", сложности явно не проверяет.
  • Рекомендация: генерировать пароли, соответствующие regex, чтобы не блокироваться при последующей смене пароля.
  1. Требования к окружению/очистке
  • Пользователей можно добавлять и удалять между тестами.
    • Удаление: POST /deleteUserRequest?userId={username}. Возможны отказы, если за пользователем есть связанные сущности/заявки (existsComponentsCountForUser).
  • Массовые HTTP-эндпоинты для «очистки тенанта» отсутствуют (такие операции есть только в DAO-слое). Для повторяемых API-тестов лучше создавать новых уникальных пользователей и удалять их через /deleteUserRequest.
  • Команды можно удалять через /deleteTeamRequest?teamId=…, но часто блокируются связями; лучше не трогать системные команды INFRATEAM/STAGINGTEAM.
  1. Полезные эндпоинты для тестов
  • Аутентификация/контекст: GET /getAuth — возвращает текущую информацию о пользователе/роли/tenant и др.
  • Пользователи:
    • POST /addNewUser (JSON UserInfoModel)
    • POST /deleteUserRequest?userId=…
    • GET /getUserDetails?userId=…
    • GET /showUserList?teamId=…&pageNo=1&searchUserParam=…
  • Справочники:
    • GET /getAllTeamsSU (teamId/tenantId)
    • GET /getRoles, GET /getRolesFromDb
  1. Замечания по безопасности и заголовкам
  • Все POST/DELETE требуют заголовка X-XSRF-TOKEN со значением одноимённого cookie (XSRF-TOKEN). Cookie устанавливается при посещении/логине. JSESSIONID — для сессии.