Всем привет! Меня зовут Александр, в hh.ru я занимаюсь автотестами. В статье про оценку тестового покрытия мы затронули тему интеграционных тестов. В этом материале я расскажу, как у нас обстоят дела с пирамидой тестирования в целом. В hh.ru более 200 микросервисов, которые тестируются на различных уровнях. У нас, как и в классической пирамиде, таких уровней три, а сейчас мы активно запускаем еще один — контрактные тесты.

Поехали! 

Что за контрактное тестирование?

Тестирование контрактов гарантирует, что две стороны способны взаимодействовать друг с другом благодаря изолированной проверке взаимной поддержки сообщений обеими сторонами. 

Одна сторона — потребитель — определяет взаимодействие с другой стороной — поставщиком, а затем создает контракт. Этот контракт представляет собой спецификацию запросов от потребителя и ответов от поставщика. Код приложения автоматически генерирует контракты, и в большинстве случаев это происходит на этапе модульного тестирования. Автоматическое создание гарантирует, что каждый контракт отражает актуальную реальность. Итак, кратко перечислим основные плюсы контрактного тестирования:

• Такие тесты выполняются быстро и требуют минимального обслуживания;

• Быстрое определение ошибок на принимающей стороне, при изменениях в API со стороны поставщика;

• Они быстрые: им не нужно связываться с другими многочисленными системами;

• Они просты в поддержке и обслуживании. Знать систему не обязательно;

• Масштабируемы, поскольку каждый компонент может быть тестирован отдельно;

• Они позволяют вскрыть баги локально на машине разработчика или тестировщика.

Проблемы UI-тестов

Так как приложение у нас большое, то и тестов у нас тоже немало. Например, одних только UI-тестов насчитывается более 9200. При этом количество сервисных тестов значительно ниже. Вообще, у нас достаточно тестов на всех уровнях, но вот их покрытие и избыточность до определенного времени оставались неизвестными. К этому добавлялось относительно длительное время прогона UI-тестов для выходящих по несколько раз в день релизов. 

Рис. статистика за месяц 

Чтобы ускорить ТТМ, мы решили увеличить количество тестов на сервисном слое. В нашем случае это, по сути, доработанные интеграционные тесты. Они значительно быстрее е2е тестов и предъявляют более низкие требования к тестовой инфраструктуре. По сути нам нужны только тестируемые микросервисы, тесты быстрее освобождают ресурсы и не требуют дополнительного ПО, например, браузеров и всего, что они за собой тянут. 

В ходе обсуждений тесты мы решили писать внутри сервисов отдельным модулем. Основная причина — особенности релизного флоу: наши сервисы выпускаются независимо друг от друга и монорепа для таких тестов создавала бы трудности по контролю за версиями используемых сервисов. Еще это позволило бы нам упростить поддержку тестов: разработчики также вовлекаются в разработку сервисных тестов. Для этого в отдельном репозитории сделали либу-раннер сервисных тестов, в которой зашиты базовые моменты и фреймворки для всех сервисных тестов. Еще подготовили пару примеров по использованию библиотеки и написанию сервисных тестов.

Проблемы с сервисными тестами

Казалось бы, все готово и можно ожидать потока новых тестов. Но реальность оказалась прозаичной — тестов особо не было. Начали разбираться и выяснилось: тестировщикам было непонятно, с какой стороны начинать эти тесты, как их подключать в сервисы, как искать эндпоинты для покрытия, и вообще — это в самом микросервисе надо разбираться, сложно! Стали искать решение. 

И решили вот что: для старта в написании тестов достаточно иметь типовую тестовую обвязку, универсальную для любого сервиса, и в каждом из сервисов можно эту обвязку генерировать по необходимости. 

Рис. Тестовая обвязка сервисных тестов в одном из сервисов

Обвязка включала основной класс-раннер наших тестов, базовые утилитарные классы — описание нашего сервиса и фабричный маппер, базовый тестовый класс, класс с примером теста, проверяющего стандартную для каждого сервиса ручку на наличие ответа 200, различные конфиги: логгера, настройки тестов и так далее. А поскольку у нас уже имелся инструмент для генерации сервисов, мы решили расширить функциональность этого инструмента и добавить туда генерацию тестов. Инструмент написан на Python и использует Jinja для шаблонизации. 

Алгоритм шаблонизации генерации интеграционных тестов

Для шаблонизации мы разработали собственный алгоритм. Для начала создаем шаблон Jinja, в котором описываем все файлы, необходимые нам в наших тестах:

• основной класс-раннер, в котором в main методе запускаем наши тесты;

• базовый тестовый файл, в котором подключаем основные библиотеки, фикстуры и т.п., использующиеся во всех сервисных тестах;

• класс описания сервиса, в котором описываются все ручки, используемые при тестировании сервиса;

• фабричный маппер;

• работающий с сервисом тестовый класс для примера (проверка стандартной ручки на 200).

При запуске генерации указываем имя сервиса, по этому имении происходит поиск репозитория сервиса, и оно же подставляется в переменные шаблона, а также ветку для пуша нового кода в репозиторий.

Использование генерации позволило значительно увеличить количество сервисов, для которых были написаны сервисные тесты. Однако, на повестке дня оставались вопросы качества и применимости этих тестов. Этот вопрос мы решили с помощью оценки тестового покрытия. Статистика по покрытию прояснила картину количества и качества сервисных тестов. И картина нам не понравилась. 

Мы вновь стали изучать проблематику вопроса и пришли к выводу, что имеющейся генерируемой обвязки недостаточно для облегчения старта. Основные затруднения вызывала трудоемкость описания эндпоинтов, которые мы будем проверять — наполнение того самого ServiceNameApi класса. Проанализировав сервисы и оттолкнувшись от алгоритмов, примененных при подсчете покрытия сервиса, мы доработали генерацию обвязки для сервисных сервисов. 

Краткое описание алгоритма генерации

Так как разработка сервисов у нас во многом стандартизирована, то все эндпоинты описываются в *Resource.java. Соответственно их и будем анализировать. 

@PUT
  @Path("/endpoint_path")
  public void getSomething(@PathParam("pathParam") String pathParam, @QueryParam("queryParam") String queryParam) {}

Так выглядит абстрактное описание любого из эндпоинтов. Нас здесь интересует:

• тип эндпоинта, обозначаемый соответствующей аннотацией над методом;

• адрес эднпоинта, идущий в качестве параметра к аннотации @Path;

• параметры метода, помеченные соответствующими аннотациями;

• возвращаемое методом значение (обычно какая либо DTO или void).

Теперь нам надо найти в проекте все классы с описанием эндпоинтов, получить информацию по предоставляемым методам, и на основе всего этого в наших тестах сгенерировать методы для работы с этими эндпоинтами. 

С помощью библиотеки javalang распарсим файлы с эндпоинтами и сгенерируем код: 

def search_endpoint(file):
    endpoint_type = 'PUT|POST|GET|DELETE'
    endpoint_api_methods = ''
    result_code = {}
    with open(file, "r", encoding='utf-8') as f:
        tree = javalang.parse.parse(f.read())
        service_path = ''
        clazz = tree.types[0]
        endpoint_api_methods = f'\n //{clazz.name}'
        imports = tree.imports
        imports_text = ''
        for annotation in clazz.annotations:
            if annotation.name == 'Path':
                if hasattr(annotation.element, 'value'):
                    service_path = annotation.element.value.replace('"', '')
                else:
                    service_path = annotation.element.member
        if service_path[:-1] != '/':
            service_path += "/"
        for method in clazz.body:
            api_type = ''
            query_params = {}
            path_params = {}
            consume_params = {}
            endpoint_path = ''
            return_type = ''
            try:
                if ('public' in method.modifiers) and (len(method.annotations) > 0):
                    for annotation in method.annotations:
                        if annotation.name == 'Path':
                            if hasattr(annotation.element, 'value'):
                                endpoint_path = service_path + (annotation.element.value.replace('"', ''))
                            else:
                                endpoint_path = service_path + annotation.element.member
                        elif re.search(endpoint_type, annotation.name) is not None:
                            api_type = annotation.name
                    if endpoint_path == '':
                        endpoint_path = service_path
                    method_name = method.name
                    if method.return_type is not None:
                        return_type = return_type_builder(method.return_type).replace("><", ", ")
                        for type_class in return_type.split("<"):
                            for imp in imports:
                                if imp.path.split(".")[len(imp.path.split(".")) - 1] == type_class.replace(">", ""):
                                    imports_text += imp.path + ";"
                                    break
                    else:
                        return_type = 'Void'

                    for param in method.parameters:
                        if len(param.annotations):
                            if param.annotations[0].name == 'QueryParam':
                                query_params[param.name] = param.type.name
                            elif param.annotations[0].name == 'PathParam':
                                path_params[param.name] = param.type.name
                        else:
                            consume_params[param.name] = param.type.name
                    signature_return_type = return_type
                    if signature_return_type == "boolean":
                        signature_return_type = "Boolean"
                    elif signature_return_type == "int":
                        signature_return_type = "Integer"
                    elif signature_return_type == "float":
                        signature_return_type = "Float"
                    elif signature_return_type == "double":
                        signature_return_type = "Double"
                    elif signature_return_type == "long":
                        signature_return_type = "Long"
                    elif signature_return_type == "byte":
                        signature_return_type = "Byte"
                    endpoint_api_methods += f'\n  public ResponseEntity<{signature_return_type}> {method_name}(HttpHeaders headers, '
                    params_text = ''
                    for param in path_params:
                        params_text += f' {path_params[param]} {param},'
                    for param in query_params:
                        params_text += f' {query_params[param]} {param},'
                    for param in consume_params:
                        params_text += f' {consume_params[param]} {param},'
                    endpoint_api_methods += params_text.lstrip()
                    if len(params_text) > 0:
                        endpoint_api_methods = endpoint_api_methods[:-1] + ') {\n'
                        for param in params_text[:-1].split(","):
                            for imp in imports:
                                if imp.path.split(".")[len(imp.path.split(".")) - 1] == param.lstrip().split(" ")[0]:
                                    imports_text += imp.path + ";"
                                    break
                    else:
                        endpoint_api_methods = endpoint_api_methods[:-2] + ') {\n'
                    # body
                    params_string = ''
                    for param in path_params:
                        postfix = ''
                        params_string += ', ' + param
                        if path_params[param] == 'int' or path_params[param] == 'Integer':
                            postfix = '%d'
                        else:
                            postfix = '%s'
                        if endpoint_path.find("{") >= 0:
                            path = ''
                            for endpoint_part in endpoint_path.split("{"):
                                path = path + endpoint_part.replace(param + "}", postfix)
                            endpoint_path = path
                    endpoint_path = '"' + endpoint_path.replace("//", "/") + '"'
                    endpoint_api_methods += f'    String path = {endpoint_path}'
                    if params_string != '':
                        params_string = params_string[2:]
                        endpoint_api_methods += f'.formatted({params_string})'

                    endpoint_api_methods += ';\n'
                    endpoint_api_methods += '    String uri = UriComponentsBuilder.fromPath(path)\n'
                    if len(query_params) > 0:
                        for param in query_params:
                            endpoint_api_methods += f'              .queryParam("{param}", {param})\n'
                    endpoint_api_methods += '              .build()\n              .toUriString();\n\n'

                    # return
                    endpoint_api_methods += '    return this.withHeaders(headers)\n'
                    endpoint_api_methods += '           .withUri(uri)\n'
                    if api_type == 'GET':
                        if "<" in return_type:
                            endpoint_api_methods += '           .get(new ParameterizedTypeReference<>() {{}});\n'
                        else:
                            endpoint_api_methods += f'           .get({return_type}.class);\n'
                    else:
                        if len(consume_params) > 0:
                            endpoint_api_methods += f'        .withBody({list(consume_params.keys())[0]})\n'
                        if "<" in return_type:
                            endpoint_api_methods += f'        .{api_type.lower()}(new ParameterizedTypeReference<>() {{}});\n'
                        else:
                            endpoint_api_methods += f'        .{api_type.lower()}({return_type}.class);\n'
                    endpoint_api_methods += '  }\n'
            except Exception as ignored:
                pass

    imports_text = list(set(imports_text.split(";")))
    result_code = {'imports': imports_text, 'methods': endpoint_api_methods}
    return result_code

Теперь в классе описания сервиса автоматически генерируются методы для работы с его эндпоинтами. А нам фактически остается написать только тесты после небольшой проверки сгенерированного кода. 

Из-за своей универсальности генерация работает не идеально. В ней невозможно учесть особенности всех имеющихся сервисов, но как инструмент для старта — это отличное решение. В дальнейшем возможно расширить наш генератор на работу с изменениями в сервисе. Например, в сервисе добавился или изменился какой-либо эндпоинт, и с помощью повторной генерации можно автоматически добавить методы работы с ним в нашу обвязку сервисных тестов.

Заключение

Вот так нам удалось приступить к выравниванию нашей пирамиды и значительно облегчить процесс выпуска изменений. Заодно мы начали получать объективную картину тестового покрытия наших сервисов. 

В планах у нас продолжать развивать генерацию тестов и повышать количественно и качественно тестовое покрытие сервисов. 

Вот несколько советов тем, кто тоже планирует работать с пирамидой тестирования:

• Проанализируйте свою текущую пирамиду: на каких уровнях у вас наблюдаются проблемы, каковы их причины?

• Проработайте возможные решения: какие из них наиболее выгодны в плане снижения рисков и устранения проблем, какие ресурсы необходимы для реализации решений?

• Прежде чем начать работу на одном из уровней пирамиды оцените текущие ресурсы: количество сотрудников, их компетенции, степень вовлеченности и загрузку.

Закончу цитатой с демо сервисных тестов одного из наших тестировщиков: “Теперь я пишу только сервисные тесты и на е2е уровень иду лишь при крайней необходимости. Сервисные быстрее и удобнее во всем: проще пишутся, легче поддерживаются, прогоняются на порядки живее е2е”.