А кто-нить эмулировал hackney в тестах? Я хочу сгенерить ответ с

client_ref, но что-то ерунду пишу всё время.
При ответе он возвращает {:ok..... client_ref}, который надо body(client_ref) и он достаёт тело ответа.
Что-то никак не могу найти как оно делается.

мы не трогаем клиент, мы поднимаем фейковый сервер

Зачем эмулировать hackney??

а в общих чертах как подымаете? у меня тут два сервиса, тоже надо как-то мокать или эмулировать или одно из двух.

примерно так: поднимаем дополнительный эндпойнт в suite setup в тесте регистрируем в глобальном хранилище request-id и желаемый ответ тестируемый код кидает запрос в этот эндпойнт с этим request-id хэндлер эндпойнта идет в глобальное хранилище и достает ответ по request-id

Жесть какая-то. Вы про bypass слышали?

bypass чего и где

Либа такая. Выглядит так Bypass.expect(bypass, "GET", "/file", fn conn -> Plug.Conn.resp(conn, 200, "This is body") end)

помойка ебаная, если надо разные данные отправлять приходится внешний стейт колхозить

а ну у нас кодовая база на эрланге плюс я не очень понимаю, как в нем работает expect_once в условиях параллельных тестов

Ничего не понял

Считает сколько раз вызывалось и всё. Он очень простой

как ты байпасу объяснишь что надо сначала один ответ отправить, а на повторный запрос другой?

Через внешний стейт. А в чём тут проблема? Так любой request-reply делается

ну то есть, два параллельных теста, ожидающих разные ответы ты не сделаешь на нем

С моками и всем остальным ничего не сделаешь

ну я и говорю помойка недоделанная

Нет, параллельные тесты сделаешь. Там разные инстансы мок-сервера поднимаются для каждого теста

То есть любая тема для интеграционного тестирования в Elixir это недоделанная помойка. Понял

видимо да

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

не в конфиг, а в базу конфигурации, чуть разные вещи

Да, это не просто хуйня, а хуйня на блюдце с золотой каёмкой :)

а как ты иначе свяжешь эти адреса с более бизнесовыми сущностями? у нас сейчас этих эндпойнтов на проде 50 штук, из них на отдельную транзакцию используется 4 в разных ролях.

А что мешает-то эндпоинт подменить в том месте, которое вы тестируете?

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

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

На интеграционном тестировании, тестируется только адаптер. А у адаптера обычно стейта вообще считай нет, поэтому не вижу там проблемы подменить эндпоинт. На функциональном тестировании тестируется пользовательский функционал на готовых данных. Там адаптеры как раз заменяются на моки со статическими ответами Может быть у вас end to end тестирование, где всё на максимально реальных условиях гоняется. Но это вообще самый высокоуровневый вид тестирования, поэтому как-то странно его параллелить на уровне самого приложения. Можно просто запускать несколько изолированных стендов и сэкономить себе кучу седых волос

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

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

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