Как устроено наше тестируемое приложение
Давайте немного расскажу о том, как устроено наше тестируемое приложение. Это только небольшой кусок.
Как вы знаете, я уже второй год работаю над расширением функциональности тестируемого приложения, чтобы можно было попрактиковаться в работе с различными системами и видами API.
Сейчас это довольно большой "франкенштейн", в который накручено большое количество систем в учебных целях, поэтому рассматривать его структуру как применение на каком-либо боевом сервисе с высокой нагрузкой не стоит.
Тем не менее, что у нас тут есть:
- Только на текущей схеме 6 микросервисов (на самом деле их почти в два раза больше);
- Один GraphQL сервис;
- Один gRPC сервис;
- ClickHouse для сбора аналитики по успешности и неуспешности регистраций;
- Redis для кэширования информации о пользователях;
- PostgreSQL для хранения всей информации о системе;
- RabbitMQ для регистрации событий о осуществлении регистрации и других событий, а также для отправки писем на почту;
- Kafka для накопления очереди о регистрации и повторной попытки регистрации, если в процессе произошли какие-либо системные, не пользовательские ошибки.
GraphQL и gRPC сервисы по большей части дублируют функционал и контракты REST сервиса, чтобы на примере было видно, в чем схожи и чем отличаются процессы тестирования и построения фреймворков автоматизации для разных типов API.
В моей картине мира итогом прохождения всех модулей программы (которая постепенно реализуется) станет очень большой фреймворк, который затрагивает множество интеграций и систем. Овладев этим, у AQA Engineer больше не будет нерешаемых задач. А также будет происходить параллельная разработка фреймворка, который позволит автоматизировать развертывание фреймворка автотестов.
TG-сообщество | Обучение |Отзывы
Post #274
1.4K

- 💩 43
- 👍 14