https://pact.io logo
Join Slack
Powered by
Hi, im am implementing contract testing in .net. T...
# pact-net
s
Hi, im am implementing contract testing in .net. The documentation strongly suggests separating tests that generate contracts and tests that run against the stubs. So my question is - what is best way to start stub api server from contract files and ask for specific state before each test ? I want test A to run against provider with state “ABC” and test B run against same provider with state “DEF”, etc… I know i can start stub api with docker container with specific state, but to change the state for the next test i would have to restart docker container. Not convenient. I know there is a library seek.automation, that launches stub api from the code and allows to filter state for each test. But it seems it is no longer supported and breaks for .net 6. Is there a better way ? Have i missed something in Pact.NET ? It can’t be that this hasn’t been needed before :)
t
I don't know about .NET, but Pact handles this for you. You specify the state as part of the test, and it starts the server with the right expectations
s
This is the mock server you are talking about ? When you do .UponReceiving, .Given, etc. My question is about STUB server
t
I think there might be a bit of confusion - the mock server is the stub server, but with the methods you are asking about
what is best way to start stub api server from contract files and ask for specific state before each test
The best way is to use the DSL that surrounds the mock server. The stub server (alone) doesn’t have many use cases
s
This is recommendation from documentation: Ideally, your Pact tests be scoped to cover as little consumer code as possible while still being a useful exercise (ie. don’t just test a raw HTTP client call), and use as few mocked interactions at a time as possible. A better approach than using Pact for UI tests is to use shared fixtures, or the generated pact itself, to provide HTTP stubs for tests that cover all layers of your consumer.
And another: Local API stubs Pact contracts are easily turned into locally running API stubs. Pact contracts lack advanced features such as predicates that you might find in tools like mountebank, however they are useful for many situations - such as e2e tests with tools like Protractor and Karma
t
Yes that's right
The first two quote is about 1) Not mocking several interactions at once - each interaction should be independent (you use provider states to achieve this) and 2) not using UI tests to drive pact - just test the API layer of your client.
to provide HTTP stubs for tests that cover all layers of your consumer.
This means that if you absolutely must have an API available at the time of your UI tests, you can use the stubs, which will be generated from the pact contract file that you got from your pact tests. This has the advantage that you will be using the same responses that will later be verified against the real server. The second quote just says that you can totally use the contract for stubs, but it's not the right tool for mocking complex behaviour over several requests.
is to use shared fixtures, or the generated pact itself
For what it's worth, I don't use the stubs - I use shared fixtures - I talked about this somewhere around the 40 minute mark here:

https://www.youtube.com/watch?v=wkld_wRsTDE▾

(The example is in JS, but the same principle will apply to .NET)
s
Yes, thank you for the answer. It seems that the recommended route is to use something like mountebank with the same fixtures. That would of course work and will keep in line with whats written in documentation. It’s just that current stub server would be sufficient if i could just ask for specific state in each test (arrange part) and i wouldn’t need additional tool 🙂 but as you say probably stub server has limited use cases at this point
Open in Slack
PreviousNext
Powered by