The future of bypass about bypass

[lucacorti]

TLS support with automatic SSL certificates setup.

I need this to test my HTTP/2 implementation and would be willing to contribute.

[agramichael]

@ream88 any possibility of making it so that within one test I can stack two expect_once's so that the first call to the given route gets my first expect_once and the second call gets the second expect_once?
Currently the second expect_once would just redefine the first expect_once and I would get an error because the route is called twice.

[mhsdef]

Yay! Props to you and @MSch both. Thanks for your efforts.

[chrismcg]

Thanks for taking this on. I love bypass and it's great to see it getting updated.

[ream88]

@chrismcg just give me a few more days, I want to go through all issues in the backlog! 😊

[chrismcg]

@ream88 please don't take my comment as any kind of pressure to ship! I'm just happy to see a great lib get some love. I came here to see if there was a PR for the DynamicSupervisor deprecation warning so to see all the work that's been done in addition to that is great.

[ream88]

@agramichael Is #80 fixing this for you? Can you try out the master branch? 😊

[agramichael]

@ream88 that fix has been very helpful! But it's not quite what I was thinking. That allows users to redefine what the response is for the route but still doesn't allow setting multiple responses for the same route, and consuming them in order.

[mrdougwright]

@ream88 that fix has been very helpful! But it's not quite what I was thinking. That allows users to redefine what the response is for the route but still doesn't allow setting multiple responses for the same route, and consuming them in order.

I believe I'm having the exact same issue. We've added a Plug to our main controller that calls (and caches!) out to our graphql API. This now adds an extra call to all of our controller tests, which breaks their call expectations.

Since the route is the same, if we could set and check multiple responses for the same route, we could update our Bypass wrapper in one place.

[ream88]

@agramichael @mrdougwright I moved the conversation to a new issue: #95