Hello, Thanks for the update. Any plans to create a minimal API example without a startup class as this is what new .NET 6.0 projects involve (all is in Program.cs). Many thanks!

@Edwin Raju has left the channel

#453 feat: Support v4 specification for consumer tests Pull request opened by adamrodger Adds v4 specification support for consumer tests with the same API as v3 sync and async pacts Requires pact-foundation/pact-reference#264 to be fixed before it can be released, otherwise CI fails due to the keys regenerating every time. I've skipped the v4 integration tests for now with a link to the issue in the FFI repo. pact-foundation/pact-net GitHub Actions: release GitHub Actions: release ✅ 7 other checks have passed 7/9 successful checks

#456 PactVerifierSource WithDirectorySource Method Not Work Issue created by alex-zinich I have one pact test on my provider. I have a folder with different contracts with Consumer. When I run the test, it always passes, I tried changing the expected result in the contract, but the test still passed. After researching, I realized that the test does not send http requests, so it always passes. The folder is not empty, it has the contract files. When I used another method: WithFileSource, the test started sending http requests and working. pact-foundation/pact-net

Release - 4.6.0-beta.1 New release published by github-actions[bot] pact-foundation/pact-net

Hi All, We are setting up contract test for kafka events for a dotnet project and going through https://github.com/pact-foundation/pact-net/blob/master/docs/messaging-pacts.md to setup Provider test. I am able to verify the result but dont know how to publish the result without swagger file. For APi Contract testing we are running this command to publish the result.

publish_provider_contract:
	@echo "\n========== STAGE: publish-provider-contract (spec + results) ==========\n"
	${PACTFLOW_CLI_COMMAND} publish-provider-contract \
	${OAS_PATH} \
     --provider ${PACTICIPANT} \
     --provider-app-version ${VERSION} \
     --branch ${BRANCH} \
     --content-type application/xml \
     --verification-exit-code=0 \
     --verification-results './report.xml' \
     --verification-results-content-type ${REPORT_FILE_CONTENT_TYPE}\
     --verifier xunit

where OAS_PATH is the swagger path. Can someone help me how to publish the verification result without Swagger file

Hi there! I'm just starting out on Pact. My repo is github and pipeline in azure devops. In the "Gold: integrate with PR pipeline" section, one of the step says "Modify the consumer commit pipeline to tag with master branch". Can someone clarify on how to implement this? I'm assuming when it says commit pipeline, CI pipeline (triggerd on merging pull request) is being referred. This is how I'm trying to integrate with pipeline - In PR validation pipeline (triggered on creation of pull request), I published the pact with branch as "feature branch name" and consumer app version as the "git commit hash". In the CI pipeline (triggered on merge), I tried using pact-broker create-version-tag and tag with master in the CI pipeline, but --version is mandatory there and in CI pipeline I'm not able to get the right git commit hash. Also, the documentation says not to use tags anymore if branches are supported. All help and guidance are greatly appreciated.

Hi, I am trying to write a provider test for Async messaging (Kafka).... Below is the test :

public void EnsureEventApiHonoursPactWithConsumer()
    {
        string pactPath = Path.Combine("..",
            "..",
            "..",
            "..",
            // "Consumer.Tests",
            "pacts",
            "Poc.Pactflow.Kafka.Consumer1-Poc.Pactflow.Kafka.Producer1.json");

        var defaultSettings = new JsonSerializerSettings
        {
            ContractResolver = new CamelCasePropertyNamesContractResolver(),
            DefaultValueHandling = DefaultValueHandling.Ignore,
            NullValueHandling = NullValueHandling.Ignore,
            Formatting = Formatting.Indented
        };

        this.verifier
            .MessagingProvider("Poc.Pactflow.Kafka.Producer1", defaultSettings)
            .WithProviderMessages(scenarios =>
            {
                scenarios.Add("a single event", () => new NotificationSmsEvent()
                    {
                        NotificationId = 237,
                        PhoneNumber = "123456789",
                        Message = "event consumed"
                        
                    })
                    .Add("some stock events", builder =>
                    {
                        builder.WithMetadata(new
                            {
                                ContentType = "application/json",
                                kafka_topic = "products"
                            })
                            .WithContent(() => new[] {
                            
                                    new NotificationSmsEvent() { NotificationId = 237, PhoneNumber = "123456789", Message = "event consumed"}
                                }
                            );
                    });
            })
            .WithFileSource(new FileInfo(pactPath))
            .Verify();
    }

here this.verifier is the PactVerifier object.... Below is the pactfile generated by Consumer test

{
  "consumer": {
    "name": "Poc.Pactflow.Kafka.Consumer1"
  },
  "messages": [
    {
      "contents": [
        {
          "message": "event consumed",
          "notificationId": 123,
          "phoneNumber": "123456789",
          "something": "123"
        }
      ],
      "description": "some stock events",
      "matchingRules": {
        "body": {
          "$": {
            "combine": "AND",
            "matchers": [
              {
                "match": "type",
                "min": 1
              }
            ]
          },
          "$[*].message": {
            "combine": "AND",
            "matchers": [
              {
                "match": "type"
              }
            ]
          },
          "$[*].notificationId": {
            "combine": "AND",
            "matchers": [
              {
                "match": "type"
              }
            ]
          },
          "$[*].phoneNumber": {
            "combine": "AND",
            "matchers": [
              {
                "match": "type"
              }
            ]
          },
          "$[*].something": {
            "combine": "AND",
            "matchers": [
              {
                "match": "type"
              }
            ]
          }
        }
      },
      "metadata": {
        "contentType": "application/json",
        "kafka_topic": "products"
      },
      "providerStates": [
        {
          "name": "A list of events is pushed to the queue"
        }
      ]
    }
  ],
  "metadata": {
    "pactRust": {
      "ffi": "0.4.0",
      "models": "1.0.4"
    },
    "pactSpecification": {
      "version": "3.0.0"
    }
  },
  "provider": {
    "name": "Poc.Pactflow.Kafka.Producer1"
  }
}

this test is passing.... but when I am changing the contract in pact json, the test is not failing .... but when I change the description it fails...... On debugging I found that thr r no events to verify..... Am I missing anything?

I am following this document https://github.com/pact-foundation/pact-net/tree/master/samples/Messaging

#457 RFC: PactNet 5.0 PactVerifier Breaking Changes Issue created by adamrodger Introduction Below is a request for comments from the community about a potential breaking change to the Pact verifier in PactNet 5.0 Background Pact specification v4 allows both synchronous HTTP pacts and asynchronous messaging pacts to be present in the same pact file, which was a key limitation of specification v3. In PactNet 4.x we only support up to specification v3, and so the

PactVerifier

API enforces either verifying HTTP-style pacts or messaging-style pacts, but not both:

var verifier = new PactVerifier();

// HTTP style
verifier.ServiceProvider("My API", new Uri("<http://localhost:5000>"))
        .WithFileSource(...)
        .Verify();;

// Messaging style
verifier.MessagingProvider("My API")
        .WithProviderMessages(scenarios => { ... })
        .WithFileSource(...)
        .Verify();;

This means that any v4 pacts containing both HTTP and messaging interactions will fail to verify, because you can't specify both a HTTP and messaging provider on the verifier. Even though the v4 pacts themselves support shared pacts, PactNet 4.x does not. Proposal A breaking change is made to PactNet 5.x such that you can specify both a HTTP and messaging 'transport' (which is what the Pact FFI calls them internally):

var verifier = new PactVerifier("My API");

verifier
    .WithHttpEndpoint(new Uri("<http://localhost:5000>"))
    .WithMessages(scenarios =>
    {
        scenarios.Add<MyEvent>("an event happens")
    })
    .WithFileSource(new FileInfo(@"..."))
    .Verify();

The breaking changes are: •

PactVerifier

requires the provider name as a mandatory constructor parameter (otherwise it would have to be specified on both the HTTP and message transport, and they'd have to match) •

ServiceProvider

is renamed to

WithHttpEndpoint

and the provider name parameter is removed •

MessagingProvider

is renamed to

WithMessages

, the provider name parameter is removed and the messages are supplied directly instead of via an additional call to

WithProviderMessages

• This means

IPactVerifierMessagingProvider

is no longer needed and is deleted • All the

WithXSource

methods are moved to

IPactVerifier

• This means

IPactVerifierProvider

is no longer needed and is deleted Caveats/Drawbacks Both

WithHttpEndpoint

and

WithMessages

are optional in case a particular service doesn't have both types of interactions, but at least one must be provided and at most one of each type. I would ideally like these invariants to be enforced at compile time but that isn't really possible without introducing a very awkward type hierarchy. Consider: • After you add a HTTP transport you can either add a message transport also or move directly to specifying a source • If you add a message transport, you must move directly to adding a source • After you add a message transport you can either add a HTTP transport also or move directly to specifying a source • If you add a HTTP transport, you must move directly to adding a source This means you have really awkward types like:

public interface IPactVerifier
{
    public IHttpAddedButNotMessageYet  WithHttpEndpoint();
    public IMessageAddedButNotHttpYet WithMessages();
}

public interface IMessageAddedButNotHttpYet : IPactVerifierTransportsConfigured
{
    // 👇 this is a duplicate of the method above in terms of signature, but with different return type
    public IPactVerifierTransportsConfigured WithHttpEndpoint();
}

public interface IHttpAddedButNotMessageYet : IPactVerifierTransportsConfigured
{
    // 👇 this is a duplicate of the method above in terms of signature, but with different return type
    public IPactVerifierTransportsConfigured WithMessages();
}

public interface IPactVerifierTransportsConfigured
{
    public IPactVerifierSource WithFileSource(...);
    public IPactVerifierSource WithDirectorySource(...);
    // etc
}

I don't think the added complexity to the types is worth the added runtime safety in this instance, particular given this is a testing library and we can simply throw

InvalidOperationException

if you try to add the same transport twice, or no transports at all. The feedback loop is fast, the error is easy to communicate/fix, and the code isn't production code. It also creates a combinatorial explosion if in future we support more transport types. pact-foundation/pact-net

#458 RFC: Replace Newtonsoft with System.Text.Json Issue created by adamrodger Introduction This is a request for comments from the community about a proposal to replace Newtonsoft with System.Text.Json as the main supported JSON serialiser. Background PactNet 4.x and below use the Newtonsoft JSON serialiser to: • Serialise matchers to the special internal format required by FFI • Serialise dynamic request and response bodies for interactions • Deserialise message interaction contents from the FFI during verification • Serialise consumer version selectors when loading pacts from a broker during verification However, PactNet is most likely to be used with ASP.Net Core going forwards, in which the default JSON serialiser is Microsoft's own System.Text.Json package. This creates friction when working with PactNet because any custom serialisation options applied to request/response objects need to be reimplemented in Newtonsoft just to work with pact tests. This reimplementation could be incorrect because the two libraries sometimes behave differently, and therefore the worst case scenario for PactNet could easily happen - the pact tests will all pass but the service fails in production usage at runtime. Proposal All references to Newtonsoft JSON serialiser will be removed for PactNet 5.x and replaced with references to the Microsoft JSON serialiser. This will create some breaking API changes where we currently support user-supplied serialisation settings, but the proposal is simply to swap like-for-like from Newtonsoft's

JsonSerializerSettings

to

System.Text.Json.JsonSerializerOptions

. This will create a minimal impact during migration whilst still allowing us to change serialiser. Internally, PactNet will use

System.Text.Json

to serialise matchers and dynamic request/response bodies supply by users, and to deserialise message interaction requests from the FFI during message interaction verification. To the user these are entirely transparent changes. The library will continue to ship as

netstandard2.0

instead of changing to a direct .Net version so that existing compatibility is maintained.

System.Text.Json

supports

netstandard2.0

explicitly. Caveats/Drawbacks Version There is an open question on exactly which version of STJ to reference. If we pick the current version then we may prevent people from upgrading if they're on older version. If we pick an older version then which one? Breaking Serialisation Changes Any custom serialisation options applied to objects previously which were not being used may now start to be used, and so potential behavioural differences might happen post-upgrade. For example, given the class:

public class MyDto
{
    public int Foo { get; init; }

    [System.Text.Json.Serialization.JsonIgnore]
    public string Bar { get; init; }
}

In PactNet 4.x the

Bar

property would still be serialised, whereas following this change it would no longer be serialised. This behaviour seems advantageous rather than problematic, as it also wouldn't be serialised by the real API under real usage and thus the pacts were technically using the wrong format. However, there are situations where the behaviour of serialisation itself may have been altered which could potentially cause behavioural changes. It's not felt the risk is high or that the consequence is severe in these situations though. The correct action to perform in that case would ensure that the pacts and API are as close as possible anyway. pact-foundation/pact-net

#394 Support Alternative JSON Serialisers, Like System.Text.Json Issue created by tl-facundo-aita When using

.WithJsonBody

, would be nice to be able to pass in a

System.Text.Json.JsonSerializerOptions

body. Another solution would be not to serialize the when the body is already a string (maybe related to this issue #391 ) This following line is the one I want to avoid: pact-net/src/PactNet/RequestBuilder.cs Line 376 in </pact-foundation/pact-net/commit/701cb50e6a1e307ee6965079e4880d910572d7bb|701cb50> pact-foundation/pact-net

This message was deleted.

Hi All, would like to know that.., when we go for on premises PactFlow do we need to setup our own broker?? Can I have a comprehensive differences among on premises Vs SASS

#459 Messaging pacts - WithContentAsync - factory is invoked before provider state has been set Issue created by DavidJFowler When verifying a messaging pact scenario using WithContentAsync, the factory Func is invoked before a POST to /provider-states has completed. To reproduce, create a dotnet 7 console app. Add a FrameworkReference to Microsoft.AspNetCore.App in the .csproj file:

<ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

add the following package refs:

<ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.11.0" />
    <PackageReference Include="NUnit" Version="3.13.3" />
    <PackageReference Include="NUnit3TestAdapter" Version="4.4.2" />
    <PackageReference Include="PactNet" Version="4.5.0" />
  </ItemGroup>

Edit program.cs:

using Newtonsoft.Json.Serialization;
using Newtonsoft.Json;
using NUnit.Framework;
using PactNet;
using PactNet.Matchers;
using PactNet.Verifier;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using <http://System.Net|System.Net>;
using Microsoft.AspNetCore.Http;

// create pact
var pactDir = Path.Join("..", "..", "..", "pacts");
var v3 = Pact.V3("Message Consumer", "Message Producer", new PactConfig
{
    PactDir = pactDir,
    DefaultJsonSettings = new JsonSerializerSettings
    {
        ContractResolver = new CamelCasePropertyNamesContractResolver()
    }
});

var messagePact = v3.WithMessageInteractions();

messagePact.ExpectsToReceive("some events")
    .Given("events exist")
    .WithJsonContent(Match.MinType(new { MessageText = "Hello World"}, 1))
    .Verify<ICollection<MyMessage>>(events => Assert.That(events, Is.Not.Empty));

// verify pact

// configure provider states handler
var isProviderStatesCalled = false;
const string pactProviderServiceUri = "<http://127.0.0.1:9001>";
var builder = WebApplication.CreateBuilder(new WebApplicationOptions());
builder.WebHost.UseUrls(pactProviderServiceUri);
await using var app = builder.Build();
app.MapPost("/provider-states", async context =>
{
    isProviderStatesCalled = true;
    context.Response.StatusCode = (int) HttpStatusCode.OK;
    await context.Response.WriteAsync(string.Empty);
});

await app.StartAsync();

var verifier = new PactVerifier(new PactVerifierConfig
{
    LogLevel = PactLogLevel.Debug
});

var defaultSettings = new JsonSerializerSettings
{
    ContractResolver = new CamelCasePropertyNamesContractResolver(),
    DefaultValueHandling = DefaultValueHandling.Ignore,
    NullValueHandling = NullValueHandling.Ignore,
    Formatting = Formatting.Indented
};

verifier.MessagingProvider("Message Producer", defaultSettings)
    .WithProviderMessages(scenarios =>
    {
        scenarios.Add("some events", scenarioBuilder =>
        {
            return scenarioBuilder.WithContentAsync(async () =>
            {
                var events = new List<MyMessage>
                {
                    new MyMessage
                    {
                        MessageText = "Hello World"
                    }
                };

                Assert.That(isProviderStatesCalled, Is.True);

                await Task.CompletedTask;

                return events;
            });
        });
    }).WithFileSource(new FileInfo(Path.Join(pactDir, "Message Consumer-Message Producer.json")))
    .WithProviderStateUrl(new Uri(new Uri(pactProviderServiceUri), "/provider-states"))
    .Verify();

await app.StopAsync();

Console.WriteLine($"isProviderStatesCalled {isProviderStatesCalled}");

public class MyMessage
{
    public string MessageText { get; set; }
}

On running the app, the assertion

Assert.That(isProviderStatesCalled, Is.True);

fails because the POST to provider-states has not been made. Changing to WithContent works:

/* ... */

verifier.MessagingProvider("Message Producer", defaultSettings)
    .WithProviderMessages(scenarios =>
    {
        scenarios.Add("some events", scenarioBuilder =>
        {
            scenarioBuilder.WithContent(() =>
            {
                var events = new List<MyMessage>
                {
                    new MyMessage
                    {
                        MessageText = "Hello World"
                    }
                };

                Assert.That(isProviderStatesCalled, Is.True);

                return events;
            });
        });
    }).WithFileSource(new FileInfo(Path.Join(pactDir, "Message Consumer-Message Producer.json")))
    .WithProviderStateUrl(new Uri(new Uri(pactProviderServiceUri), "/provider-states"))
    .Verify();

pact-foundation/pact-net

#460 WithCustomHeader Function does not replace existing headers Issue created by RChild0916 Hello all! I'm working with pact-net as a provider using pactflow which has some bi-directional testing, and ran into an interesting issue. We recently added authentication to our API, and needed to add an auth header using the .WithCustomHeader method like so: `

IPactVerifier pactVerifier = new PactVerifier(config);
        pactVerifier
            .ServiceProvider("App.Api", new Uri(_baseUrl))
            .WithPactBrokerSource(
                new Uri(_providerUrl),
                options => options
                    .TokenAuthentication(_pactflowToken)
                    .PublishResults(
                        _providerVersion,
                        options => options.ProviderTags(_providerTags)
                            .ProviderBranch(_providerBranch)))
            .WithProviderStateUrl(new Uri(_fixture.ServerUri, "/provider-states"))
            .WithCustomHeader("Authorization", $"Bearer {tokenValue}")
            .Verify();

` The "WithCustomHeader" function seems to have an issue, which I haven't been able to discern exactly but believe it is one of two things: 1. If a header already exists within the consumer pact json, it does not replace the value as it should. 2. It is only adding an additional header, and in this case, we end up with 2 "Authorization" headers Either way, the end result is the same in that our API grabs the old token that exists within the pact file and attempts to use it, sees it is expired and throws a 401. To get this working, we removed the Authorization header from the pact file and everything ran clean from the provider side, but this lead to a new issue within pactflow. Pactflow will check the request headers against our API's OAS, and sees that the authorization header is missing and fails for the consumer side check. Is it possible to get new functionality to allow users to replace existing headers? pact-foundation/pact-net

#461 Feat/verifier refactor Pull request opened by abhi-zacharia Testing purpose pact-foundation/pact-net GitHub Actions: release GitHub Actions: Build and Test (dotnet) (macos-latest) GitHub Actions: Build and Test (dotnet) (ubuntu-latest) GitHub Actions: Build and Test (dotnet) (windows-latest) GitHub Actions: release GitHub Actions: Build and Test (dotnet) (macos-latest) GitHub Actions: Build and Test (dotnet) (ubuntu-latest) GitHub Actions: Build and Test (dotnet) (windows-latest) ✅ 1 other check has passed 1/9 successful checks

@Calum Maciver-Whyte has left the channel

Hello, was wondering if someone can help me out. I cloned the consumer and provider repos for the bi-directional testing examples. They both use a

make

file that references

pactfoundation/pact-cli

. But this does not exist in the repo so it fails. can't see any sign of this folder anyway. Anyone know what the deal is?

Hello I have a question about Pact and API versions. I've found the following question that was already answered before: https://pact-foundation.slack.com/archives/CLS16AVEE/p1680267252981199 So, according to the answers above, Pact is capable of dealing with multiple API versions. I was indeed able to successfully publish a manually prepared swagger.json file with two paths /api/v1/mail and /api/v2/mail to Pactflow. But I wonder whether this is the recommended way? I have doubts because the "dotnet swagger" command, which is the standard command for generating swagger files in dotnet projects, does not seem to support the generation of a swagger file with multiple versions, or at least not in a straightforward way. The "dotnet swagger" command seems to be designed to create one API version per file: For example: dotnet swagger v1 myapp.dll --output v1/swagger.json or dotnet swagger v2 myapp.dll --output v1/swagger.json So, the question arises whether it would be possible to publish two files with two different API versions for the same provider version? Or is one file with two paths the only (and the proper) way to publish two versions for the same provider version? Or generally speaking, what is the proper way to handle versioning of APIs with regards to Pact?

So, the question arises whether it would be possible to publish two files with two different API versions for the same provider version? Or is one file with two paths the only (and the proper) way to publish two versions for the same provider version?

It’s the latter. we only support a single OAS document for a given provider

I’m sure there are tools that can merge two OAS files though, so that could be an option - merge before publishing to PactFlow

Another option is to version the Provider in Pactflow e.g.

ProviderV1

and

ProviderV2

#462 Please support --fail-if-no-pacts-found in verifier configuration Issue created by jvmlet Please support

--fail-if-no-pacts-found

in verifier configuration pact-foundation/pact-net

#463 Please support eachItem Matcher Issue created by jvmlet Please support

eachItem

matcher for collection attributes pact-foundation/pact-net

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:

.WithProviderStateUrl(
	providerStateUrl, 
	(e) => {
		e.WithTeardown();
		Console.WriteLine("Provider state teardown executed.");                        
	});

Hey everyone, I wanted to use PACT with our gRPC Services, is there any guide for that?

also is there any guide for contribution? the link on the github readme page is broken CONTRIBUTING

#464 Matching fails on double / float / decimal with integer value Issue created by Manny651 When a match condition is a decimal number with an integer value, there is a verification mismatch when the JSON value is represented by a integer. Example:

var pact = Pact.V3("My API", "Consumer").WithHttpInteractions();
var body = new { value = 10m };

pact.UponReceiving("A request with decimals")
    .WithRequest(<http://HttpMethod.Post|HttpMethod.Post>, "/test")
    .WithJsonBody(body)
    .WillRespond()
    .WithStatus(HttpStatusCode.OK);

pact.Verify(context =>
{
    var client = new HttpClient { BaseAddress = context.MockServerUri };
    client.PostAsJsonAsync("/test", body).Wait();
});

Gives Verification mismatches:

Copy code

{
  "actual": "10",
  "expected": "10.0",
  "mismatch": "Expected '10.0' to be equal to '10'",
  "path": "$.value",
  "type": "BodyMismatch"
}

It looks like the library expects the decimals to be serialized by Json.NET (which always serializes floats and decimals with a decimal point), unlike System.Text.Json or other frameworks. pact-foundation/pact-net

does anyone know how to handle provider states for running provider tests against the actual api? We're using Docker to run it as its own instance against a test db before running the tests.