Комментарии 4
Интересно, код тестов с вызовами pg.execute/http.request/queue_service.publish приведен в качестве примера или это реальные тесты? Такой подход не порождает дублирования в однотипых кейсах (test_login_ok, test_login_invalid, test_login_locked, etc). ИМХО, напрашивается какая-то клиентская обертка, если кейсов достаточно много.
Можно вынести дублирующийся код в функции или, ещё лучше, в фикстуры pytest.
В будущем хотим сделать кодогенерацию http-клиентов по Swagger, и, возможно, какую-то кодогенерацию моков других микросервисов по их Swagger.
А какую обертку вы предлагаете для queue_service.publish?
Для pg.execute можно было бы использовать SQLAlchemy, но не хочется еще и в коде тестов описывать структуру БД, слишком усложнит тесты.
Да, я как раз это и имел ввиду (а не использование ORM) — дублирующийся код можно вынести в функции и фикстуры, функции могут захотеть объединиться в классы, могут нарастать слои абстракции — и через некоторое время может появиться почти полноценная клиентская библиотека для тестируемого приложения. При условии, конечно, что необходимо более или менее полное покрытие функционала, граничных значений. Интересно будет узнать, как вам удается бороться со сложностью в коде таких тестов. Статься и тема очень интересная, спасибо!
Если тесты становятся такими сложными, что используют какие-то классы, абстракции, то уже нужно тестировать и сами тесты) Этого хотелось бы избежать.
Пока таких проблем не возникало, большинство наших микросервисов не настолько сложные. Но, уверен, что подобные проблемы появятся, будем думать. Сейчас у меня проверенного решения нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Функциональные тесты в Циан