This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Для сервисов, которые сделаны на базе micro или имеют protobuf описание есть возможность использовать автоматические юнит-тесты с использованием csv+json файлов. Основная идея заключается в том, что для добавления нового тест-кейса не нужно никаких правок код или знаний программирования. Достаточно положить группу файлов в соотвествии с определенной структурой директорий. Примеры ниже приведены для MVC версии тестов в рамках deposit-grpc сервиса и директории с тестами tests tests/config.json - конфигурационный файл сервиса, является копией конфига из консула и не содержит логинов и паролей к внешним системам. Вместо настроек подключения к бд следует использовать в секции dsn (или в той секции, где указываются параметры подключения к бд слово mock://) tests/common_test.go - основной файл, запускающий тесты. Должен содержать две части: TestMain(m *testing.M) - парсинг конфигурационного файла, запуск сервиса с последующим запуском тестов Test_All(t *testing.T) - получение экземпляра мок для бд, создание грпц или хттп клиента, редирект stdout/stderr в буфер и последующий запуск тестов tests/data/NN_Service.Method - NN любое число, лучше с ведущим нулем для натуральной сортировки в списке Service - имя сервиса в protobuf файле Method - имя метода сервиса в protobuf файле Таким образом для каждого метода сервиса может быть больше одного теста. Если результат теста зависит от предыдущего запроса, такие запросы следует располагать в нумерации в порядке следования. Возьмем для примера метод GetInfo сервиса grpc с директорией tests/data/01_Service.GetInfo: GetInfo_db.csv - файл csv, в котором содержатся данные используемые для mock ответов бд. Таких файлов может быть несколько для разных версий запросов. Данный файл содержит следующую мета-информацию:
- # query .get_info_v3. - после ключевого слова query и пробела после него идер pcre регулярное выражение. По данному условию mock для бд будет понимать какие данные нужно отдавать на какой запрос * # args {"ID_List":["12345"]} - после ключевого слова args следуют аргументы запроса, в зависимости от значения аргументов могут mock может выдавать разные данные на один и тот же запрос
-
columns ID|VARCHAR|NULL,.... - после ключевого слова columns следуют имена колонок и типы данных, которые могут быть. Так как mock при обработке csv файла не умеет определять где NULL значение строки, а где пустая строка, данное описание помогает подсказать правильный тип при отдаче данных
GetInfo_req.json - файл, содержащий тестовый запрос к сервису в формате json. Так как для запуска тестов используется фреймворк micro и все grpc/rest сервисы понимают входящий запрос и ответ в виде json GetInfo_rsp.json - файл, содержащий тестовый ответ от сервиса в формате json. Так как для запуска тестов используется фреймворк micro и все grpc/rest сервисы понимают входящий запрос и ответ в виде json GetInfo_err.json - файл, содержащий тестовый ответ об ошибке в формате json. Так как для запуска тестов используется фреймворк micro и все grpc/rest сервисы понимают входящий запрос и ответ в виде json. Если файл присутствует, считается, что запрос должен вернуть ошибку. Если файла нет, считается, что запрос должен вернуть ответ без ошибки.