Hi guys. I'm exploring <v4.5.0> PactNet version th...
# pact-net
d
Hi guys. I'm exploring v4.5.0 PactNet version that introduces Provider state teardown. Can someone explain what is a use case of the feature? Description says teardown is supposed to be executed after each interaction. I have interactions that have different provider states. So in this case the same teardown will be applied for different provider states. Also I tried it and noticed that the delegate code is executed only once. Although test log shows several "Running teardown provider state change handler..." message equal to amount of interactions. Here is how I called it:
Copy code
.WithProviderStateUrl(
	providerStateUrl, 
	(e) => {
		e.WithTeardown();
		Console.WriteLine("Provider state teardown executed.");                        
	});
m
My understanding is that the teardown hook should be per state. The main idea is to reset the particular state that was setup, as there may be multiple
d
Right, this is what I would expect from that feature
m
Sounds like a big somewhere
Mind raising an issue please?
d
Yes, I will
@Adam Rodger (pact-net), can you please shed light on the intention of Provider states teardown feature implemented in v4.5.0
Managed to figure it out bananadance smile In order to have it work as we expect - teardown for each provider state after each interaction, we need to perform these steps: 1. Turn on teardown feature
Copy code
.WithProviderStateUrl(
	providerStateUrl, 
	(e) => { e.WithTeardown(); });
It will send an extra request to "provider-states" middleware with new property "action":"teardown". 2. In a test you can define Setup and Teardown delegates for each provider state. 3. In "provider-states" middleware call corresponding delegate depending on received "action" property value (for setup use "action":"setup").
🙌 1
Maybe it will help others how got confused by that feature 🙂
🙏 1
m
Thanks. Perhaps we should document this somewhere on the .NET code base - where do you think would be best David?
d
Examples in README.md look simple and do not cover other things. I think updating this sample might be useful. I can try to do it when I have free time
a
It's not really a feature of PactNet itself - it's just a URL that you provide, so that could be implemented in a number of ways. You may even have an entirely different service running in a totally different place handling the provider state changes (e.g. by inserting some data into a database that the real service would use).
d
I have never thought in that direction...interesting 👍
👍 2
a
Yeah that's why we don't ship a provider state middleware 👍 You could never possibly cater to all needs without producing lots of different approaches, none of which would ever quite be right. There's an example of how it might be done in the samples section, but that's far from the only way. For example, you may not even be using ASP.Net Core, you might be using another web framework entirely. So implementing a provider state handler is an exercise left to the reader, so that the solution they get fits their needs exactly. It's out of scope for PactNet itself to do this.
m
Is there a middle ground where you could provide a provider state middleware (or proxy) and allow for a custom URL? We allow this in Node JS and Pact Go. 99% of people use the state handlers, which are essentially functions mapped to named provider states on the verifier
i.e. provide a sensible default that most would just use, and provide a way to “DIY” it for the advanced user
d
Good observation, Matt. I agree with Adam that there are might be many ways of implementing it. But let me give an example of my project. We've been digging into Pact and contract testing topic for about year or more. And we created some kind of a wrapper framework for PactNet. That aimed at providing a simplified interface for other developers. So that anybody can kick start it quickly omitting learning curve. For now there are around 20 teams (microservices of our product) that do contract tests along other types of tests. And as I can see not many people understand the topic as I do, simply because they don't have to. For sure I try to provide the same capabilities as PactNet has to not limit our "users". As for PactNet maybe we can enhance existing code sample showing different features or keep documentation relevant. It will help adopters. Maybe I could help with documentation sometime