а что хочется тестировать? корректность обработки определенных данных полученных от сервиса? КОрректность отправки данных в сервис? корректность поддержки протокола взаимодейтсвия с сервисом? корректность обработки ошибок или недоступности сервиса?

Корректность отправки и корректность обработки ошибок и недоступности.

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

Сервис дергается из celery, тут видимо будет идти речь о 2e2 тестировании. Я рассматриваю два варианта:
1. В тестовом окружении поднимать контейнер с фейковыми сервисом, имитирующим API (там не очень много, до десятка эндпоинтов, но логика может быть сложная).
2. Вынести взаимодействие в отдельный микросервис-контейнер и мокать внутри что-нибудь в тестовом окружении.

* есть входные данные, им соспоставляем желаемый вызов стороннего сервиса. проверяем, что он соотвествует, можем ничего не отвечать, что дальше происходит с нашим приложением уже не важно.
здест по желанию можно даже делать dependency injection реализации протокола сервиса, если реализация протокола отдельно оттестирована, тогда можно не использовать внешний мок
(стадия функционального тестирования)
* ошибки лучше все-таки тестировать фейковым сервисом, вхоные данные приложению, принимаем запрос в фейке, заоно проверяем, что он правильный, возвращаем ошибку. проверяем, что поведение приложения ожидаемое
(стадия интеграционного тестирования)

в любом случае не надо пытаться реализовывать логику сервиса
фейк должен делать только следующее:
* инициализироваться ожидаемым запросом и фейковым ответом на него
* получать запрос
* проверять, что он ожидаемый
* возвращать фейковый ответ

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

и это интеграционное тестирование скорее. e2e - это если бы был взят инстанс реального сервиса и поставлен в тесты и мы бы проверяли всю систему целиком вместе с реальным сервисом до некой конечной точки

Да, пожалуй интеграционное.

Ох, спасибо, буду думать дальше. Но я хотя бы определился с направлением мысли..

псевдоком это выглядит примерно так

def some_func(service):
    return service(2) + 1

def my_test():
    def my_fake(arg):
        assert arg == 2
        return 3
    result = some_func(service=my_fake)
    assert result == 4

def some_func(service):
    return service(2) + 1

def my_test():
    def my_fake(arg):
        assert arg == 2
        return 3
    result = some_func(service=my_fake)
    assert result == 4

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

Да я эту мысль понял, я немного по-другому это себе представлял.. Все-таки планировал часть логики реализовать, но это и вправду дурная затея.

мне кажется, я уже третий день подряд эту ссылку кому-то даю:)
https://youtu.be/oO-FMAdjY68

Кажется, на днях я уже встречал это где-то.. )

Я обычно хранилища поднимаю все в контейнерах + мокаю запросы к внешним ресурсам (мокаю иногда по-разному, иногда на уровне HTTP, если можно так сказать, иногда на уровне кода, хз есть ли аналоги таких моков в питоне)

Но в любом случае это интеграционные.

е2е не пишу, у нас разработчики их не пишут.

У меня весь вопрос возник на фоне трудноотлаживаемого кейса:
Внешний сервис на время прилег и таски по отправке данных перестали корректно выполняться. Ну, это вполне штатная ситация, не страшно. А потом уже при доступном сервисе таски начали падать. Я это видел вживую, выполнял руками целевой сценарий и видел ошибку в логах. В этот же момент руками выполнял то же, что делает код таски - и все работало. К такому я как-то не привык и, честно написал клиенту, что я понятия не имею что делать ) Через час оно само по себе разрулилось и продолжило работу в штатном режиме.
Вот я и подумал, что я всю эту историю никак не могу протестировать, ни автоматически, ни руками, т.к. это не воспроизвести. А потом уже стал думать в целом о покрытии тестами этого взаимодействия.

Тут полезно иметь логи ответов сервиса и чтобы он в ответы с ошибками какие-то указания хотя бы на свои логи или ошибки слал.
Вот auth0 при ошибке всегда в ответ пихает код ошибки. И ты уже в их дашборде или через API можешь посмотреть полный лог: что клиент слал, что ему ответили, что потом происходило и почему ошибка возникла. Отладка взаимодействия двух систем - задача обеих систем.

Ответ сервиса был ReadTimeoutException 😂 Сейчас занимаюсь прикручиванием Graylog, чтобы можно было как-то восстановить картину происходящего.

Ищу начинающего веб разработчика PHP
#Москва #офис #работа

Задачи
#Москва #офис #работа

Задачи
• Работа в content downloader x1
• Настройка готового парсера для opencart (ocstore 2.3)
• Работа над целом спектром задач в ходе интеграций CMS OcStore и realcrm

Условия
• Работа в офисе (м. Технопарк, ул. Лобанова, д. 8)
• Зп и график обсуждается, от ₽30 тыс.

Собеседование
• Опыт работы не обязателен
• Индивидуальное собеседование в офисе

Приветствуется
Знания: Python, Selenium, request, bs4, aiohttp, pandas, peewee, postgres. Datacol, x-parser light.

Откликнуться