Для сервисов, которые сделаны на базе 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. Если файл присутствует, считается, что запрос должен вернуть ошибку. Если файла нет, считается, что запрос должен вернуть ответ без ошибки.