Части 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Логирование:
45. Логи пишем на русском языке.
Если видим, что где-то в приложении есть логи на другом языке - исправляем на русский. Это правило не касается логов, которые пишут сторонние библиотеки.
46. Для удобства поиска по логам, рекомендуется логировать request_id (trace_id).
Request_id (trace_id) получаем из соответствующего заголовка запроса.
При обращении к другим пиложениям также добавляем request_id (trace_id) в заголовок запроса.
47. Приложение, запущенное на стенде dev, demo, prod должно отдавать логи в STDOUT (консоль) в JSON-формате.
Это позволит собирать и парсить логи для работы с ними в ELK.
48. Для записи логов в реактивном приложении используем асинхронный аппендер.
Написание тестов
49. Интеграционные тесты на контроллеры, проверяющие аутентификацию, пишутся отдельно от интеграционных тестов, проверяющих бизнес-логику.
50. В интеграционных тестах на контроллеры, проверяющих аутентификацию, все остальные зависимости заменяются моками.
51. Тестирование логики отдельных классов должно выполняться с помощью юнит-тестов.
Интеграционные тесты с поднятием контекста Spring использовать для этого не нужно, т.к. это существенно увеличивает общее время прохождения тестов и замедляет разработку.
52. Локально, на ПК разработчика, проект и интеграционные тесты должны запускаться с профилем 'local'.
При запуске интеграционных тестов с профилем 'local' тестовая база данных поднимается в тест-контейнере. При запуске с любым другим профилем тест-контейнеры не поднимаются.
53. При запуске тестов в пайплайне GitLab, интеграционные тесты не должны запускаться с профилем 'local'.
Нецелесообразно в пайплайне тестам самим поднимать базу данных в тест-контейнере. Гораздо выгоднее для тестов использовать базу данных, предоставляемую самим пайплайном.
54. Каждый интеграционный тест должен создавать в базе данных необходимые ему записи и по завершении теста - удалять их.
Использование единого для всех тестов скрипта миграции для наполнения тестовой базы данных тестовыми данными, недопустимо.
55. Для написания тестов всем необходимо использовать библиотеку jUnit5.
Команда может принять решение использовать для написания тестов любую другую библиотеку. Тут важно наличие единообразия и отсутствие зоопарка тестовых библиотек.
56. При написании тестов НЕ рекомендуется использовать функцию assertThat().
Эта функция, в случае ошибки, не выводит в лог ожидаемое и фактически полученное значения и не предоставляет способа их сравнить в консоли ИДЕ. Вместо неё рекомендуется использовать другие функции библиотеки Assert: assertTrue(), assertEquals() и т.д.
57. Для тестирования асинхронного кода, когда ответ может прийти не сразу, необходимо использовать библиотеку org.awaitility:awaitility-kotlin.
Писать в тестах delay {}, Thread.sleep() и т.п., чтобы перед проверкой подождать, пока отработает асинхронная логика, неправильно.
58. Для создания мока keycloak для интеграционных тестов, необходимо использовать библиотеку com.tngtech.keycloakmock:mock-junit5.
Команда может использовать любое другое решение, единое для всех тестов.