Dotnet6 pactnet450 #8
Conversation
There was a problem hiding this comment.
we can remove the consumer class fixture, that was responsible for setting up the ruby backed lifecycle methods
| <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.9.4" /> | ||
| <PackageReference Include="PactNet" Version="4.5.0" /> | ||
| <PackageReference Include="PactNet.Output.Xunit" Version="1.0.0" /> | ||
| <PackageReference Include="xunit" Version="2.4.1" /> |
There was a problem hiding this comment.
updated deps for pact-net 4.5.0
tests/ConsumerPactTests.cs
Outdated
| LogLevel = PactLogLevel.Debug | ||
| }; | ||
|
|
||
| pact = Pact.V3("pactflow-example-consumer-dotnet", "pactflow-example-provider-dotnet", Config).WithHttpInteractions(port); |
There was a problem hiding this comment.
rather than calling our ConsumerPactClassFixture we setup our provider in test.
| .WithHeader("Content-Type", "application/json; charset=utf-8") | ||
| .WithJsonBody(new TypeMatcher(products)); | ||
|
|
||
| await pact.VerifyAsync(async ctx => |
There was a problem hiding this comment.
We wrap our system under test ProductClient().GetProducts(...) inside a VerifyAsync block.
This starts our Pact.V3(...) mock provider, and can give us access to a dynamically created URL/Port if required.
We then perform our assertions on our result from our consumer method GetProducts(...) rather than on the expected Providers response. This is the traditional unit testing style, and ensures you are testing consumer behaviour rather than providers implementation detail
notes
Traditionally we wouldn't recommend committing pacts to source control, and explicitly ignore it in more repos, however it is nice to see the delta between the latest ruby backed pact-net (3.0.2) and the latest rust backed pact-net (4.5.0)