https://pact.io logo
Join Slack
Powered by
With apologies for asking something that I see has...
# pact-net
m
With apologies for asking something that I see has been asked before... I'm evaluating pact.io and I'm a microservices / .net software engineer. I ran into the issue where TestServer doesn't appear to work with the provider test side because it doesn't expose a real TCP socket. I saw a lot of talk about it but I'm still not clear on whether it's a no-go or whether it can be done. If I could get some clarification that'd be helpful!
l
@Yousaf Nabi (pactflow.io) I think we need to get some examples around this! Could you co-ordinate!
m
You need to start your actual provider, if that’s what you’re asking?
e
TestServer relies on special http clients (WebApplicationFactory:CreateClient) that know how to talk to it without going to network
thank you 1
You can't pass httpclient to the pact verifier but you can expose a proxy network address if you really want to, as mentioned in the issue comment. (I don't think this is ideal workaround, and I'd rather suggest following the samples)
👍 1
y
Hi @Matt Lund, Could you point to these discussions and it may help provide additional context for discussion, and we may need to clarify in the docs.
With apologies for asking something that I see has been asked before..
I saw a lot of talk about it but I’m still not clear on whether it’s a no-go or whether it can be done
You are reliant on real network calls being replayed by the client (in this case the Pact verifier) in order to issue calls to your provider application under test which has been started. Thanks for the additional context and links @Eugene Baranovsky . as I have not tickled .NET for many many moons, and have very little language specific advice to provide
m
Thanks for the clarification. TestServer = no go. It's not our only option but it would have been the preferred option.
a
Yeah this keeps coming up. You can't use the 
TestServer
. It runs in memory and thus the Rust core has no way of calling it. You have to start the host properly, like all the samples do.
I'm going to put a note about that in the README now, although I imagine this won't be the last we hear of this 😄
☝️ 1
b
Yeah this keeps coming up. You can't use the 
TestServer
. It runs in memory and thus the Rust core has no way of calling it.
True, but it's understandable why .NET developers familiar with WebApplicationFactory reach for it when trying to implement Pact. WebApplicationFactory does more than just mock out the HTTP stack; it also provides a convenient/familiar API for customizing the SUT (Provider) in various ways that are useful in the context of Pact testing. E.g. replacing out-of-process dependencies with mocks, disabling authn, etc. Pact-Net doesn't have a polished story to tell around that** -- kind of an exercise for the implementer to roll their own WebApplicationFactory-like solution. ** as far as I can tell. Would be very happy to shown otherwise!
I'd add that in our case, this has been a difficult barrier to acceptance with Pact-Net. We're a small shop with a large investment in WebApplicationFactory- based "Integration tests". We use a lot of in-memory mocks (Moq) to support those tests -- very similar to the examples in the Microsoft documentation: https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-6.0#inject-mock-services We need to do same/similar setup in Pact Provider tests, but without WebApplicationFactory to do that heavy lifting, it's a real burden. I'm hopeful there's some way to steal the "useful bits" from WebApplicationFactory (e.g. host factory resolver) and share the common setup code between the different test projects, but I haven't dug into it very deeply yet.
Open in Slack
PreviousNext
Powered by