has joined #pact-net-development

has joined #pact-net-development

has joined #pact-net-development

has joined #pact-net-development

has joined #pact-net-development

First up, going to re-release the change from the other day as a `3.0.0` , with the async fix from Martin (cool to see that Just Eat are still using Pact!)

hey matt.. my tests will be a little delayed, but no hurry.. i wil get a grip on C# Rust then gat back to this group

*Update on the Rust work* ? :white_check_mark: the Rust FFI bindings for the provider interface are good to go ? :ok: the FFI bindings for the consumer side are about 80% there (no request matching rules or generators on the headers, query string, path). But by the time the work is done to set up here, the Rust code may be ready. See https://github.com/pact-foundation/pact-go/blob/feat/v3-ffi-verifier/v3/internal/native/mockserver/mock_server.go for the Golang raw FFI boundary.

The provider verifier is almost a drop-in replacement for the current ruby one. You also have two choices in terms of replacing it ? Use the CLI and spawn it (just like the Ruby one, except it would be an executable) ? Use the FFI boundary

It?s also SUPER FAST. In the JS spike I?ve done, this is how fast the test runs: ```? native git:(spike/ffi-provider) ? time node test.js node test.js 0.10s user 0.02s system 102% cpu 0.117 total```

When I showed Tim (another maintainer) he actually went back to the IDE to look for the problem, assuming that it failed so quickly there must have been an obvious code error

Greg - I think we?ll need to get some help from our new contributors for the mocking. Neil is trying to step away, and Beth knows this much C# -> `0`

lol... fair enough neil wants to step away.....

using the FFI boundary would have the advantage we can pass results/data/errors back for handling them in the appropriate library. CLI is easier but we get isolated from the run, getting something back requires us to use a headless prompt and read in the stdout and stderr streams

has joined #pact-net-development

Hi. I had a question regarding the version number. Why we upgraded to 3.0.0 since we are not in sync with the pact specs 3.0? Wouldn't it have been more adequate to have a minor version change? => 2.7.0 Thanks

Hi everyone, nice to see we are starting to have some contributors. I will go over the PACT 3.0 specs and see what little time I can get to help. Keep you all posted.

The version of the library is independent of the spec version. There was a breaking change in this version from a semver perspective, which we believe is the appropriate versioning mechanism at this moment. But we should all get together and start to agree on our governing processes. I'll be up on my computer in the next hour and will see how we can find some timea to chat

hi yann - welcome to the dev corner

ok I understand. That is actually not a bad idea. If I were to start looking at a solution, could I then start with the 3.0.0? To see the feasibility of some features of the 3.0 specs.

Judging by the timezones we have, a 10pm call here in Australia is 8am on the west coast (US/Canada) and 2pm in Central Europe

@matt.fellows has a polly for you!

10pm is a pain in the butt Greg, so if you can?t make it, we could schedule another time together

In the meantime, we need to scratch together an agenda

:thread: on an agenda :point_down:

Whipped together a quick document that we can collaborate on: https://docs.google.com/document/d/1I8Ww4v4td5t1d3uNrKEjGAKHnbsR9osBotz5xLMBCqw/edit#

If you could please share an email, i?ll add you all as editors so we can work on this asynchronously

Done. Thanks Matt

has joined #pact-net-development

Hi matt.. done.. my machine has been a royal pain today.. slack crashed out

Thoughts or feedback?

hi matt, my "good" machine played up. 25th at 10pm

Thanks Greg!

everything crashed or threw errors... sheesh.. upgrade is coming

:grimacing:

On my nachine or the doc?

I put unit testing and rfc referencing up

So only 2 responses, might need to find another time for all?

@jacek.helper are you keen? Hugo has let me know he can't contribute at this time

@greg595au sorry to do this, but I actually now have a 10pm meeting (my fault for not blocking the calendar, but I was also hoping to get more responses to the above)

@yann.courtel is still keen to join

@yann.courtel are you free up to 1 hour earlier? (i.e. 1pm your local time)

@greg595au is 9pm local time workable? If so, i?ll get an invite out shortly

Hi matt.. 9 pm works..

Apologies, we only need to align 2 timezones? now. Alternatively, we wait for others to respond to see if it?s worth rescheduling

But I reckon we get cracking

I?ll record and share

Yep. Looks like for me it's 1PM. I'll be there!

:raised_hands:

Anyone wanting to join tonight to discuss the future/roadmap of Pact .NET can join at 9pm AEST / 1pm CET Pact .NET Tuesday, 25 May ? 9:00 ? 10:00 pm Google Meet joining info Video call link: https://meet.google.com/hzm-njxs-kwt Or dial: +61 2 9051 3678 PIN: 497 948 990# More phone numbers: https://tel.meet/hzm-njxs-kwt?pin=4275417422534

We?re on https://meet.google.com/hzm-njxs-kwt?authuser=1

recording https://drive.google.com/file/d/1Tk6AlRK36NS8QisdmCZ62UEOs_utCUA_/view?usp=sharing

(it will be denied by default for those who didn?t attend, but i?ll approve when you try to open as I?ll be notified :stuck_out_tongue: )

Sorry I have missed that plus I have couple of extra things in this week so this way or another it will be hard to still yet another hour from my sleep time. Next week looks more promising to me.

Agenda from that meeting and working doc: https://docs.google.com/document/d/1I8Ww4v4td5t1d3uNrKEjGAKHnbsR9osBotz5xLMBCqw/edit#

no worries

I?ll aim for some time in the next day or so to document more of what happened. See the main channel for the video recording. The last 30 are about the FFI bindings stuff

has joined #pact-net-development

Hi all - quick update from me about something I'm doing locally. I've started porting from the Ruby implementation to the Rust version via the FFI interface for consumer tests (not provider yet). I get the feeling we may need to make some breaking changes because of the differences between them. For example, the Ruby version supports supplying your own TLS cert but the Rust version appears to only be able to use a built-in self-signed cert but allows you to retrieve the CA programatiicaly so you could technically trust the cert at runtime. We'd either have to remove custom TLS from PactNet or try to add custom TLS to pact-rs instead. Another awkward change which I'm just in the middle of is that the `Path` and `Query` params on the request setup are of type `object` but the Rust implementation wants them supplied in string key/value pairs (with an index as well). At the moment my version supports Path and Query of `string` type (by splitting on `&` and then each segment on `=` for query) and we can definitely support `Dictionary<string, string>`, but I think in the current version lots of people use `dynamic` with an anonymous object. We'd have to use some reflection to retrieve the properties from the `dynamic` I think. You'd have to throw an exception if those params were of any type that we didn't support. Either that or we make a breaking change and stop those two properties on request from being of type `object` and pick something that's easier to support. I'm sure ther are more challenges but those are the two off the top of my head :slightly_smiling_face: I've not got to matchers yet so I imagine there's plenty more trouble headed my way :smile:

cool!

OK so the rust interface for those are fairly low level

The TLS cert is something we can add in later - honestly, using TLS in most cases is just overkill. But we should support it eventually

For version 1, I would consider ignoring completely

Cool I'll drop those args then

Can you please elaborate on the query/path problem?

(we do need a strategy to move forward so we?re not constantly adding breaking changes, but let?s separate the two problems for now)

on the indexed query/header values, it?s because it now supports multiple _values_ for a given key

i.e. if you had `?foo=bar&foo=baz` That could be represented more strictly than the current version. The index is for the array values, so it?s just `0` for others

ditto for headers

But appreciate it is a bit clunky - you would need to map/iterate over any objects that translate to it. So yes, probably breaking change

So the Ruby version can take pretty much any argument for query because it's of type `object`(code https://github.com/pact-foundation/pact-net/blob/c2b8dfeeeebf2312bb37d7c54137802b117720bc/PactNet/Mocks/MockHttpService/Models/ProviderServiceRequest.cs#L20 ) but the Rust FFI interface `with_query` just takes a string key and string value (plus an index so you could repeat query params with the same name)

That's fine for the Ruby one because http://JSON.Net will just serialise that properly if you pass a dynamic object

Like ```Query = new { foo = "bar" }```

But you can also do `Query = "foo=bar&baz=bash"` and just pass it a string, which works also

I imagine you can also pass it a dictionary like the `Headers` property takes, but I've never tried that

yeah, that?s definitely not easily doable now. FWIW the current implementation for query strings is a constant source of issues, so I think the newer version is actually better because it?s more explicit, but it?s different

The problem with having an API of type `object` is we have no idea how consumers are actually using this thing, so trying to support all the current usages is near-impossible. I think we need to either pick a sensible-subset to support, or change from `object` to something more usable for us

in pact-go, I?m moving to a more builder style pattern. You could then over load methods to take different types, and provide better type support etc.

I'd personally prefer some kind of `QueryBuilder` class so that it can internally keep everything as key/value pairs and also support adding the same key multiple times (which eventually ends up as `foo=bar&foo=whatever`

Ha, snap

:slightly_smiling_face:

But yeah, that'd be another breaking change on top of dropping custom TLS

you?ll see a similar conundrum when dealing with bodies. Because it now supports binary payloads/multipart etc. you might want to provide different typed options

e.g. a `.JSON(?)` for json bodies

Yeah at the moment `Body` is just `dynamic` so it can be literally anything and is expected to be JSONified

We'd need that to be like an `IPactBody` and then have different implementations for it, so one for JSON and one for binary

sounds reasonable

One of the challenges at the moment is for users knowing what they can actually put in there.

examples only go so far

Yeah for sure. The current version is super flexible by effectively skipping the type system and delegating the problem to http://Json.Net, but that's not so easy in Rust land where you don't get to defer problems to someone else :smile:

yeah. But it?s not ideal for users either, because they have to work trial and error

A related problem is the v2/v3 problem - you don?t want somebody using a v3 matcher in a v2 test. Ideally, you want the type system to prevent this.

Yep definitely. If we're OK with the idea of making breaking changes there and using the type system more to guide users into the pit of success, I'm all for that

a major upgrade to Rust would warrant a breaking change, but we need general community consensus. A place to consider this is creating a GH issue with an RFC like proposal - keen to submit that?

It starts sounding like a more fundamental rewrite though once you do stuff like that :smile:

well, it may well need it - I?m not sure

Yeah I can submit a proposal. I'll probably carry on with where I am at the moment until I hit an inevitable brick wall, and then write up what I think is best to do next

(I don?t maintain pact .NET but am helping out whilst we build up our new set of maintainers)

The earlier you get it into the public domain the better so we can give feedback/guidance etc., and also ensure somebody else doesn?t waste their time doubling up

I have a very very early version available here: https://github.com/adamrodger/pact-net/tree/feature/rust-interop In the middle of adding the query support

cool - have you tackled matchers yet?

i.e. I can see https://github.com/adamrodger/pact-net/blob/feature/rust-interop/PactNet/Matchers/Type/MinTypeMatcher.cs still uses the old Ruby style

I?m aiming to publish some guidance in the next week about what matchers can go into places, and the JSON structure you can give the FFI

But if you want some inspiration, https://github.com/pact-foundation/pact-go/blob/feat/ffi-consumer/v3/matcher.go mighthelp

e.g. an `eachLike` https://github.com/pact-foundation/pact-go/blob/feat/ffi-consumer/v3/matcher.go#L26-L29 Also JS => https://github.com/pact-foundation/pact-js/blob/feat/v3.0.0/src/v3/matchers.ts

JSON structure looks like this: ```{ 'pact:matcher:type': 'type', value: [template], }```

So the API I've got to at the moment now looks like this for consumer tests (with matchers not done yet) using the Rust FFI integration internally and maintaing support for using a remote service: ```[Fact] public async Task GetAllEvents_WithNoAuthorizationToken_ShouldFail() { var config = new PactConfig { SpecificationVersion = "2.0.0", DefaultJsonSettings = new JsonSerializerSettings(), /* ... set whatever ... */ LogDir = "./logs", PactDir = "./pacts", Overwrite = true }; IInteractionBuilder interactions = new PactBuilder(config).ServiceConsumer("consumer") .HasPactWith("provider") .UsingNativeBackend(8080, IPAddress.Any); // or .UsingRemoteBackend(new Uri("http://remote.example.org"); var interaction = interactions .UponReceiving("a request to retrieve all events with no authorization") .Given("there are events with ids '45D80D13-D5A2-48D7-8353-CBB4C0EAABF5'") .WithRequest(HttpMethod.Get, "/events") .WithHeader("Accept", "application/json") .WillRespond() .WithStatus(HttpStatusCode.Unauthorized) .WithHeader("Content-Type", "application/json; charset=utf-8") .WithJsonBody(new { message = "Authorization has been denied for this request." }); var consumer = new EventsApiClient(_mockProviderServiceBaseUri); await Assert.ThrowsAnyAsync<Exception>(() => consumer.GetAllEvents()); interaction.Verify(); }```

The fluent API ensures that you can't try to configure the request/response out of order and stuff, effectively using the typestate pattern

I think we'd distribute the FFI stuff as a NuGet using the `native/` layout and then NuGet will automatically restore the env-specific FFI libraries without that stuff having to pollute the PactNet core code. I've also separated out the "backend provider" so we could keep supporting the Ruby version, the Rust native version and the remote version all in one package. Or we could ship like a `PactNet.Providers.Native` and `PactNet.Providers.Remote` etc in the same way you have things like `Microsoft.Extensions.Configuration.Json` shipping custom providers on top of a library with the core logic that's provider-agnostic

Great progress!!

One comment I?ll make (and I say this without much knowledge of the nuget ecosystem). Ideally, we bundle the rust package into the artifact. We get a lot of complaints from enterprises behind proxies when dependencies need to be downloaded dynamically during instnall (e.g. pulling a release down from GH releases). I don?t think you?re proposing it, but _just in case_

Yeah it'd be bundled up with a NuGet, which matches how it works now. Currently you need to install `PactNet` and also like `PactNet.Windows` because that contains the Ruby dependencies. I'm proposing we ship a single `PactNet.Native` instead of one per OS which contains all native deps. NuGet will unpack the correct one at build time depending on the OS (it's a single nuget with like `native/win-x64/mock_server_ffi.dll` inside it, with a path per binary)

Anyway, I've pushed an updated version which now actually manages to call the Rust mock server, can recognise failed interactions and does all the appropriate unmanaged cleanup stuff. However, it keeps thinking every request is unexpected so there's probably some kind of issue there (I assume it's mismatched headers?) If you want to build it locally you'll have to unload the unit tests as I've not sorted those yet. Wanted to make sure we agree on the API/layout before spending too much time on them. The samples compile though. Branch here: https://github.com/adamrodger/pact-net/tree/feature/rust-interop

I'm hoping I don't need to specify the Host/Connection headers. I'm sure the Ruby version didn't require that

So yeah, that kinda exposes a pretty brutal experience when using the Rust backend from xUnit - it doesn't capture stdout or anything so you've got absolutely no idea what the backend is doing. My interaction says it's unexpected (which is likely a bug in my new interop code) but you can't tell what interactions it _thinks_ are registered so that you can spot which bit went wrong. You don't get any logging from the Rust backend at all and you can inspect the internals of it in the debugger or anything.

Ah. We were discussing this with the JS implementation - when we use the FFI bindings there, we get the standard out (which is nice), but we don?t have the ability to say ?hey, can you log to this file? (which would be great, and is what the Ruby impl lets you do)

I think we may want to look at extending the Rust side to be more configurable with logging

Also, hi! It?s really great to see so much progress on the .NET engine!

I've extended the Rust FFI locally for my testing with log4rs so maybe I could contribute that back also if it turns out to be useful

I raised it as an issue against pact-reference anyway in case someone there has a better idea

I?d do the same. compressed, they?re probably not that big that it makes a big deal for people these days

Hmmm, so yeah I think I may have hit a bit of a wall on this. Without the logging it's really difficult to know what's going wrong, and the way that you typically do these calls from .Net doesn't really suit how the Rust library is laid out. In C# you do this: ```//Arrange const string eventType = "DetailsView"; this.interactions .UponReceiving($"a request to retrieve events with type '{eventType}'") .Given($"there is one event with type '{eventType}'") .WithRequest(HttpMethod.Get, "/events") .WithQuery("type", eventType) .WithHeader("Accept", "application/json") .WithHeader("Authorization", $"Bearer {Token}") .WillRespond() .WithStatus(200) .WithHeader("Content-Type", "application/json; charset=utf-8") .WithJsonBody(new[] { new { eventType } }); //Act var result = await this.authorisedClient.GetEventsByType(eventType); //Assert result.Should().OnlyContain(e => e.EventType == eventType); this.interactions.Verify();```

The problem is that the `Verify` call will probably never happen in the failure situation because the client call will typically throw an exception and the test will fail early. That means you don't get the output of `mock_server_mismatches` from the Rust side to see what went wrong, and without the stdout/stderr output you can't even go and investigate it.

You could wrap it in a `try/finally` so that `Verify` is always called and then you get the mismatches output, but that's putting a lot on the caller to make sure they always do that. I don't think that's the way to go

Also the entire process crashes when I try to use the `free_string` method to deallocate the string result from `mock_server_mistmatches` so that's also a problem :smile: I think I need to make the P/Invoke interop return an `IntPtr` instead and use `Marshall.PtrToString` to get the string out, then pass the same pointer back to free it

And also if `mock_server_mismatches` returns some errors, how come `mock_server_matched` returns true?

that sounds like a bug

If you can raise an issue, I/@uglyog can look into that

has joined #pact-net-development

I still think the framework should be responsible for extra checks, rather than relying on the caller. i.e. `Verify()` should be called by Pact .NET, not relied upon by the user

Interesting. I think I do call `free_string` and haven?t seen this. I?ll double check next time I?m there

TBH it?s probably not critical it get called anyway, because the test process is pretty short lived and any memory will be freed at the end of the test process

but still, nice to be correct :wink:

I've managed to get the string to deallocate safely now (it does need to be IntPtr to safely deallocate) but now it crashes on cleanup_mock_server instead :joy: Perhaps I shouldn't even be trying to free this string at all

Raised https://github.com/pact-foundation/pact-reference/issues/107

Yep, that's the issue. I think that's a bit of a wrinkle in the Rust FFI tbh - most of the methods that return strings say you need to free them afterwards with `free_string` but the `mock_server_mismatches` method _doesn't_ need the result to be passed to `free_string`. If you do pass it to `free_string` then the process crashes when you later call `cleanup_mock_server`, presumably because it tries to double-free the mismatches.

So yeah, I'm pretty stuck now tbh. I've added file logging to `mock_server_ffi` and I can get logging out of all the mock server bits, but the matcher modules don't log anything (presumably they use a different log than the global one and/or override the log somewhere internally?). None of my requests will match against registered interactions - I can see the interactions being set up properly and the request coming in looks identical to me. Without seeing the output of the matcher module I totally can't work out why this won't match my requests. Log output: ```2021-05-27 14:45:49 INFO - Successfully initialised logger 2021-05-27 14:45:49 DEBUG - Created new pact between consumer Event API Consumer and provider Event API with ID 1 2021-05-27 14:45:49 DEBUG - Set specification version on pact 1: V2 2021-05-27 14:45:49 TRACE - registering event source with poller: token=Token(0), interests=READABLE | WRITABLE 2021-05-27 14:45:49 DEBUG - Started mock server on 127.0.0.1:6868 2021-05-27 14:45:49 DEBUG - Added new interaction with ID 1 to pact 1 : a request to retrieve event with id '83f9262f-28f1-4703-ab1a-8cfd9e8249c9' 2021-05-27 14:45:49 DEBUG - Updated description for interaction 1: a request to retrieve event with id '83f9262f-28f1-4703-ab1a-8cfd9e8249c9' 2021-05-27 14:45:49 DEBUG - Added provider state for interaction 1: there is an event with id '83f9262f-28f1-4703-ab1a-8cfd9e8249c9' 2021-05-27 14:45:49 DEBUG - Added request to interaction 1: GET /events/83f9262f-28f1-4703-ab1a-8cfd9e8249c9 2021-05-27 14:45:49 DEBUG - Added request header to interaction 1: accept application/json 2021-05-27 14:45:49 DEBUG - Added request header to interaction 1: authorization Bearer abcdef1234567890 2021-05-27 14:45:49 DEBUG - Added response status to interaction 1: 200 2021-05-27 14:45:49 DEBUG - Added response header to interaction 1: content-type application/json; charset=utf-8 2021-05-27 14:45:50 DEBUG - Added response body to interaction 1: Present(606 bytes) 2021-05-27 14:45:53 TRACE - registering event source with poller: token=Token(1), interests=READABLE | WRITABLE 2021-05-27 14:45:53 DEBUG - Creating pact request from hyper request 2021-05-27 14:45:53 DEBUG - Extracting query from uri /events/83f9262f-28f1-4703-ab1a-8cfd9e8249c9 2021-05-27 14:45:53 TRACE - path_and_query -> /events/83f9262f-28f1-4703-ab1a-8cfd9e8249c9 2021-05-27 14:45:53 INFO - Received request Request ( method: GET, path: /events/83f9262f-28f1-4703-ab1a-8cfd9e8249c9, query: None, headers: Some({"accept": ["application/json"], "host": ["localhost:6868"], "connection": ["Keep-Alive"], "authorization": ["Bearer abcdef1234567890"]}), body: Empty ) 2021-05-27 14:45:53 DEBUG - Request did not match: Request was not expected - Request ( method: GET, path: /events/83f9262f-28f1-4703-ab1a-8cfd9e8249c9, query: None, headers: Some({"accept": ["application/json"], "host": ["localhost:6868"], "connection": ["Keep-Alive"], "authorization": ["Bearer abcdef1234567890"]}), body: Empty ) 2021-05-27 14:45:53 WARN - Mismatch: {"method":"GET","path":"/events/83f9262f-28f1-4703-ab1a-8cfd9e8249c9","request":{"body":"","headers":{"accept":"application/json","authorization":"Bearer abcdef1234567890","connection":"Keep-Alive","host":"localhost:6868"},"method":"GET","path":"/events/83f9262f-28f1-4703-ab1a-8cfd9e8249c9"},"type":"request-not-found"} 2021-05-27 14:45:53 INFO - Writing pact out to '../../../pacts/Event API Consumer-Event API.json' 2021-05-27 14:45:53 DEBUG - Writing new pact file to "../../../pacts/Event API Consumer-Event API.json" 2021-05-27 14:45:53 DEBUG - Shutting down mock server with port 6868 2021-05-27 14:45:53 DEBUG - Shutting down mock server with port 6868 - MockServerMetrics { requests: 1 } 2021-05-27 14:45:53 DEBUG - Mock server a681ad3a-2695-4577-aea7-b56cd5e8f462 shutdown - MockServerMetrics { requests: 1 }``` AFAIK it's supposed to ignore the `connection` and `host` headers, and the headers are supposed to be case-insensitive (I've tried both types) and no luck. Second problem: The Ruby implementation has a "clear interactions" method which you call after each unit test. Without this, whenever one interaction fails then every subsequent test fails because the previously-failed interaction still shows up as a mismatched interaction until the entire test run ends. The Rust version doesn't seem to support that.

OK I've managed to add some logging that's worked out there are no interactions inside that Pact, which is why nothing is matching (and presumably why there's no logging from the matching module - there's nothing to actually match against so it'll never get called)

Strange, I?ve not had this problem, but also I have been working with a local copy of the FFI bindings because the new matchers only got merged yesterday

Are you working with the released artifacts or locally compiled ones?

Should we maybe setup a call early next week to pair througch a bit of this? You?ve got the energy, so it makes sense to capitalise on that

So if I've read this code correctly - do you need to set up your interactions before you can start the mock server? `MockServer::new` calls `Pact::thread_safe()` : https://github.com/pact-foundation/pact-reference/blob/2b581d177ec6975bf1d2d94a9fa81f0b19792fb8/rust/pact_mock_server/src/mock_server.rs#L96-L107 And `Pact::thread_safe` creates a clone of the pact wrapped in an Arc/Mutex: https://github.com/pact-foundation/pact-reference/blob/2b581d177ec6975bf1d2d94a9fa81f0b19792fb8/rust/pact_matching/src/models/mod.rs#L925-L927 Doesn't that mean the server is hosting whatever the pact happened to look like at the point the server was started? If so, if you haven't established your interactions yet then the clone will have none, which would match with what I'm seeing.

Yes, previous version was a separate process so it had to startup at the beginning of the test run, and was a stateful mock server. Each test had to then communicate with it via HTTP.

The Rust version is in-process, so we start up a new mock server for each test with the Pact required for that test.

There is not need to communicate with it via HTTP, we just pass it everything directly via FFI call.

It is way more efficient, but you need to setup the expected interactions first, and then start the server.

Ah, oh dear. Yeah that's not gonna match how PactNet works at all

There's quite a foot gun there as well - it looks like it should work given how the old version works but actually it's silently falling. You're adding interactions to an old clone of a pact that nothing is using, and nothing warns you of that

The current versions of pact libraries have you set up and verify each interaction in a separate unit test, with the server started once at the beginning then the pact file written at the end. You can't support a "unit test per interaction" workflow if you've got to set up all your interactions ahead of time and then verify them all together at the end.

No, each interaction can be for a separate test. They get merged into the pact file.

So each test can setup the interaction for that test

But how if you can't start the server yet? The server needs to start at the beginning of the test run, but then you can't add any further interactions into it

This is the current way that PactNet works: https://github.com/pact-foundation/pact-net/blob/master/Samples/EventApi/Consumer.Tests/EventsApiConsumerTests.cs#L24-L57 ? The server starts once at the beginning ? Each test establishes an interaction ? You do the real HTTP call ? You verify the results of the HTTP call

So you need to the verify inside each test, otherwise they won't fail when things go wrong

And you need to do the HTTP call inside each test, so the server has to be started at that point, which means all interactions must already be registered, and therefore the test can't establish the interaction

No wonder I've spent a couple of days struggling to understand why it doesn't work :smile: Those interactions that it looks like I'm adding are actually having no effect because they're being added to a pact that's not being used by the mock server

I would do something like (excuse my http://non-.Net code): ``` _mockProviderService.Given("there are events with ids '45D80D13-D5A2-48D7-8353-CBB4C0EAABF5', '83F9262F-28F1-4703-AB1A-8CFD9E8249C9' and '3E83A96B-2A0C-49B1-9959-26DF23F83AEB'") .UponReceiving("a request to retrieve all events with no authorization") .With(new ProviderServiceRequest { Method = HttpVerb.Get, Path = "/events", Headers = new Dictionary<string, object> { { "Accept", "application/json" }, } }) .WillRespondWith(new ProviderServiceResponse { Status = 401, Headers = new Dictionary<string, object> { { "Content-Type", "application/json; charset=utf-8" } }, Body = new { message = "Authorization has been denied for this request." } }); _mockProviderService.RunTest { mock_server -> var consumer = new EventsApiClient(mock_server.url()); //Act //Assert await Assert.ThrowsAnyAsync<Exception>(() => consumer.GetAllEvents()); } ```

Yeah you can't do that. That test will always pass no matter what

The `runTest` method can call start and the beginning and then verify at the end

Plus it's a definitely not an idiomatic way to write C#, and very different to how it is now.

The only way I can see that working is if we start and stop the mock server for each every unit test, but that means it'll be starting and stopping potentially hundreds of times in a given test run, and writing the pact file hundreds of times also. You could only support the merge strategy for the pact file, never overwrite, which would be problematic also. I imagine starting and stopping on the same port over and over will eventually cause problems as well, like the OS just won't accept that happening loads of times or something.

It does do that. I've implemented that pattern in Pact-JVM and Rust. It is very fast to spin up a server and shut it down again

How do you support overwrite for the pact instead of merge?

Each mock server gets it's own port

overwrite won't be work

Oof. Yeah I'm really not sure this is the best approach

@matt.fellows wants to have a chat next week, but it works in Rust, Java/Jvm and JS, so I'm pretty sure it will work in .Net

@matt.fellows How do the JS and Go versions work? Do they start and stop the server for each interaction as well?

Yep

(sorry just making dinner but will try and follow up later)

The trick is to clear out the pact file before use

You can probably get it to work in .Net yes, but you'll end up with quite a non-idiomatic API and you'll only be able to support merge instead of overwrite (which is really annoying when working locally)

The benefit is that you can do this in parallel

Well, I'll give it a go and see where we end up. Got to say I'm sceptical though :smile: We'll need to drop remote server support as well, and that feature was literally just added

And, some feedback for the Rust FFI end - if the server has already started then you should probably get an error back if you try to add/modify interactions. At the moment it accepts them but actually they have no effect, which has really confused me for 2 days now

Can you raise an issue for that, otherwise I might forget

Yep, will do

How do you prevent the pact file from becoming corrupted if you start multiple servers all sharing that one file and run the tests in parallel?

You could end up with 2 tests trying to both write the file at the same time

There is a memory lock as well as a file lock

Memory lock ensures thread access, file lock for multiple processes

OK so multiple servers accessing the same file are sequential anyway? Is that for the entire time the file is being accessed? Otherwise if you lock on read, release the lock, do the processing, lock again then write, you'd have a race condition where an interaction could get dropped from the file

The memory lock is for the whole `write_pact` method, the file lock is for the entire read -> merge -> write, but only if the file all ready exists

There is a potential race condition there, but only for multiple processes accessing the file

OK so the API you naturally end up with if it's "interaction per test" but also "start/stop server for every test" is this. I think that's kinda OK tbh. One problem is if the user has all the tests run in parallel and specifies the same port in multiple tests (instead of omitting the port and letting the backend allocate one dynamically)

I think it?s worth calling out that the new .NET API does not have to look the same as the old. That might be ideal in terms of migration, and I?m not saying we should change it, but if we?re going to revisit what it looks like, now is the time.

There are several classes of errors / problems this new design addresses. I?m not saying it couldn?t be improved, but it certainly solves a bunch of problems we frequently see as maintainers

That looks pretty good to me! I?m assuming there was something like `using` that could be done here - happily it exists.

I almost removed the ability to choose a port, but if I did, I knew that somebody would immediately ask. But we want to discourage it for that exact reason

I?ll have a think about how to do that remotely.

If you do want to catch up, let?s see if we can find an overlapping time. We?re exactly 9 hours ahead of you, so I?m assuming you?re based in UK/EU. We could do 5-6pm or something one weeknight (or later, but after 9pm here is usually once we have the gremlins down for sleep)

Mon, Tues and Thurs are looking :ok_hand: at the moment

OK, I've got it working! :tada:

For simple consumer tests (as in ones with fixed bodies, not ones containing matching rules) then it works absolutely fine and writes out the pact file etc. Bodies containing matchers don't work, but I think we were expecting that at the moment?

I'll have to have a look how you guys do the matching rules stuff in JS/Go and then try and get that working as well

One potentially breaking change I've noticed in the Rust backend btw - the pact file that's written out now doesn't have the same name. In the Ruby version my file would be called `my_consumer-my_provider.json` but in the Rust version that would be `My Consumer-My Provider.json` which has spaces instead of underscores and hasn't been forced to lowercase. I could maybe see that causing problems (especially the spaces).

And now the matchers are fixed as well since I've got a spare moment this evening, and all the consumer tests in the sample now work :tada: They really are quite slow though. I imagine starting and stopping the server over and over is quite a bottleneck. I can try out the current stable version for comparison but I don't remember them being this slow.

Struggling to get the verification to work though. My code constructs the args properly but when it calls in to the `verify` method it gets a status code of 4 (invalid arguments). If I pass these exact same argument into the `pact_verifier_cli.exe` though then they work absolutely fine. Since I can't get the stderr logging I have no idea which of those it doesn't like.

I wonder if those file path separators need double-escaping

The FFI takes newline delimited arguments

That's unbelievably slow.

My node JS tests run in in fractions of a second

It looks ok to my eyes though. We'll get the logging so it can goto file and stdout (configurable)

Matchers on bodies should definitely work.

I added support for the other parts recently also

But that may not be released it only just got merged

The file name shouldn't be relevant for functionality but probably good to clean that up as you say

It's the content that matters

I've had a bit of a thought on that as well. Logging to a file would be great, but what would be even better is if you could init with a string as a sink (I've not checked it there are any crates for that or a way to redirect stdout though). A file is a good first step, but in reality the UX would be annoying. Your test would fall and it could only say "go and check the file to find out why", and the file would have output from every test. If it could log to a string sink instead (per server port, like with mismatches) then the test could retrieve it and include it in the test output. That would be a really good UX.

Yep that's a good idea

Or if it just returned the log at the end (like fetching the mismatches)

Writing to the same address might be problematic, but providing an option to fetch the current log might be simpler and safer. What do you think?

Yeah that'd be best. I can include that in the xUnit output then, so everything you need to know for your failing test should just be there

Perhaps we should've gone the route of just calling the CLI like the ruby one did after all :joy:

Just so I'm clear - we talking consumer or provider side for the logging? Might get some time for a play later (dinner Joe :wave:)

That's a really good idea. I'll try implement it today

That's be awesome, thanks

As an FYI, this is an example consumer test (just one) that goes through the full cycle. It?s not passing through a test framework like Jest/Mocha but I think is still indicative of the performance

And my machine is far from quick!

Hi matt and co - sorry I have been offline this weekend.. my mac (replacing the existing machine) is almost ready - just emails and get the project from git to go

@pact544 @matt.fellows I've been playing around with this. While I've got the logs being captured into a buffer, we can't stop the logs being interleaved from different threads.

The problem is that the matching code runs on a thread pool, so it could be running on any number of threads.

The only way it might work, is having a thread pool per mock server, but that would be wasting thread resources

Ah makes sense.

How expensive are we talking? Could we reduce the number of threads per server?

It's actually a little more complex. It is currently configured for one thread in the pool, but it is async on a Tokio runtime, so we can't use thread local state because different parts of different mock servers might be scheduled at any given time.

I'd seen it as a property on the mock server object, which you know at the point you run the consumer tests so you can pass a mutable reference to its log buffer around. Probably be a bit awkward passing it around instead of holding it somewhere centrally though

The problem is the logging infrastructure is global, so you can't know which mock server the log entry is for

Yeah, I assume that's the change that needs to happen

(if we go that route)

Is the verifier side any easier or is that also on multiple threads? At the moment there's no way to get anything other than a generic failed error code, so it's even more needed there

You're probably unlikely to be running other pact tests, although I suppose you could be both a consumer and provider

Or perhaps we store the failures as actual objects and return those instead of a string representation of everything? Then multi threaded isn't a problem and it's not via global infrastructure

Are you saying the the xunit framework doesn't let you see the stdout at all?it just swallows it and discards it

Essentially, yes

Crazy

I'd like a JSON representation of the errors though

That is something on my list of things to investigate (ala what the mock server does but in reverse)

Yeah I think that's fine. For consumer tests it already stores the mismatches I think, and just converts to JSON as part of the FFI? We could do the same for verification errors.

What's nice about structured data is you can convert them back into tests results (so you get a set of green ticks/crosses on provider side too)

Yeah that'd be cool. Not sure how that'd work on the .Net side but I could see that for JS

Ooh, Tokio supports task local state: https://docs.rs/tokio/1.6.1/tokio/task/struct.LocalKey.html

Might be able to push the mock server ID onto that, and then accumulate the log entries by that value

:raised_hands:

Most frameworks have hooks to be able to generate tests. I actually haven't done it for JS because too many frameworks to do it for. But Go was easy because just one

More generally though, structured data I think gives flexibility

E.g. a simple/quick wrapper could just use the default Rust output, complex integrations could do as they please

I fixed this btw :thumbsup: I was passing an arg like `--loglevel info<newline>--foo bar` instead of having a newline between an argument and its value. Now that everything is separated by newline it's passing in fine, but I get a general verification failure and no logging so can't tell why.

I've added the following to `pact_provider_ffi/lib.rs` by the way to get some file logging out: ```/// Init the library with logging directed to a file as well as stdout /// /// # Safety /// /// Exported functions are inherently unsafe. /// /// # Errors /// /// Errors are returned as non-zero numeric values. /// /// | Error | Description | /// |-------|-------------| /// | -1 | Unable to convert the file name to a valid string | /// | -2 | Unable to create a logging sink with the given file name | /// | -3 | Unable to initialise the logger | /// | -4 | A null pointer was received | #[no_mangle] pub unsafe extern "C" fn init_with_file( file_name: *const c_char, level_filter: LevelFilter, ) -> i32 { if file_name.is_null() { return -4; } let file_name = match CStr::from_ptr(file_name).to_str() { Ok(file_name) => file_name, Err(_) => return -1 }; let file = match fern::log_file(file_name) { Ok(f) => f, Err(_) => return -2 }; let result = fern::Dispatch::new() .format(|out, message, record| { out.finish(format_args!( "[{}][{}] {}", record.target(), record.level(), message )) }) .level(level_filter) .chain(std::io::stdout()) .chain(file) .apply(); match result { Ok(()) => 0, Err(_) => -3 } }``` It uses `fern` since `pact_matching_ffi` already uses that, except that sets up a thread local logger instead of a global one, which isn't what you need when doing verification via FFI really.

As an aside, is there any particular reason the Rust code doesn't use the standard `rustfmt` and `clippy` conventions? Whenever I'm doing Rust code I always get in the habit of doing a `cargo fmt` before committing anything (you could set it up as a pre-commit hook even) and making sure I've sorted all clippy warnings out

Ron added the interfaces from the matching ffi lib, so I think that would be redundant now

Task local vars is working! :tada:

```$ src/consumer-verification basic ../../rust/target/debug/libpact_mock_server_ffi.so This is consumer-verification 0.0.0. Setup logging result: 0 Running basic pact test Mock server started on port 46267 Executing request against http://localhost:46267/mallory?name=ron&status=good * Trying 127.0.0.1:46267... * Connected to localhost (127.0.0.1) port 46267 (#0) > GET /mallory?name=ron&status=good HTTP/1.1 Host: localhost:46267 Accept: */* * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < access-control-allow-origin: * < access-control-allow-headers: * < access-control-allow-methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH < access-control-expose-headers: Location, Link < content-type: text/html < content-length: 28 < date: Mon, 31 May 2021 04:49:08 GMT < * Connection #0 to host localhost left intact "That is some good Mallory." OK: Mock server verified all requests, as expected --------------- MOCK SERVER LOGS --------------- [DEBUG][pact_mock_server::hyper_server] Creating pact request from hyper request [DEBUG][pact_mock_server::hyper_server] Extracting query from uri /mallory?name=ron&status=good [INFO][pact_mock_server::hyper_server] Received request Request ( method: GET, path: /mallory, query: Some({"name": ["ron"], "status": ["good"]}), headers: Some({"accept": ["*/*"], "host": ["localhost:46267"]}), body: Empty ) [INFO][pact_matching] comparing to expected Request ( method: GET, path: /mallory, query: Some({"status": ["good"], "name": ["ron"]}), headers: None, body: Missing ) [DEBUG][pact_matching] body: '' [DEBUG][pact_matching] matching_rules: MatchingRules { rules: {} } [DEBUG][pact_matching] generators: Generators { categories: {} } [DEBUG][pact_matching::matchers] String -> String: comparing '/mallory' to '/mallory' using Equality [DEBUG][pact_matching] expected content type = '*/*', actual content type = '*/*' [DEBUG][pact_matching] content type header matcher = 'None' [DEBUG][pact_matching::matchers] String -> String: comparing 'good' to 'good' using Equality [DEBUG][pact_matching::matchers] String -> String: comparing 'ron' to 'ron' using Equality [DEBUG][pact_matching] --> Mismatches: [] [DEBUG][pact_mock_server::hyper_server] Test context = {"mockServer": Object({"href": String("http://127.0.0.1:46267"), "port": Number(46267)})} [INFO][pact_mock_server::hyper_server] Request matched, sending response Response ( status: 200, headers: Some({"Content-Type": ["text/html"]}), body: Present(28 bytes, text/html) ) [DEBUG][pact_mock_server::hyper_server] body: '"That is some good Mallory."' ------------------------------------------------ ------------------ GLOBAL LOGS ------------------ [WARN][pact_matching::models] No metadata found in pact file "<create_mock_server>", assuming V3 specification [WARN][pact_matching::models] No metadata found in pact file "<create_mock_server>", assuming V3 specification [DEBUG][pact_mock_server::mock_server] Started mock server on 127.0.0.1:46267 [DEBUG][pact_mock_server::server_manager] Shutting down mock server with port 46267 [DEBUG][pact_mock_server::server_manager] Shutting down mock server with port 46267 - MockServerMetrics { requests: 1 } [DEBUG][pact_mock_server::mock_server] Mock server f23a4853-09ad-4ce7-b489-3c7a51a4cba5 shutdown - MockServerMetrics { requests: 1 } ------------------------------------------------```

Global log entries are not associated with any mock server, and each mock server will be able to fetch it's log entries regardless of threads

Expect for the thread local support, but we should consolidate that

Clippy is run as part of the CI build. I'm generally apposed to formatting tools (like lints), as I don't feel they provide any value apart for people who get agitated with formatting mismatches. I prefer the commit diffs to only contain the functional changes. But that is just me.

@matt.fellows has to deal with me always removing his lint tools and deleting his commit hooks.

Speaking of which, latest build has failed due to a clippy violation

I don?t like any formatting/linting that requires humans to do anything. But my OCD does like consistent formatting. More importantly (and I could be wrong about Clippy), I want those tools to tell me when I?m doing something stupid, or if I could be doing it better - better I want them to do it for me

I absolutely don?t want to get into dumb arguments about spaces/tabs, the size of the tabs etc.

That?s one thing Go does well - this is the format you use. No exceptions, don?t waste valuable brain capacity on it

wow! Awesome

I need to verify it working with multiple threads, but is a problem for another day

Clippy has been pretty good, you can learn to be better at Rust by fixing the warnings

is that something that gives you compile time feedback, or in the IDE? or better question - how should I use it :slightly_smiling_face:

But the build I just fixed was not a useful one

It's CLI at the moment, but I'm sure you can set something in the IDE

There is a VSC plugin, but look like it is slow

> Look like it is slow It?s ok, my rust compiler is also slow

This one? :stuck_out_tongue:

Yeah, that! :smile:

haha thanks, found that one too

IntelliJ IDEA supports it as well

It might be time for me to bite that bullet

Clippy in IntelliJ feels really slow, and that's on my metabox, CLI is better

You can just run `cargo clippy` on the project

Yeah I like the "just follow the format" and "tool does it for me" approach that `cargo fmt` does for me. I'm really struggling to read the code locally because it's so dense (I have some sight problems) so I've had to reformat to be able to follow it. That does make it difficult to contribute though.

So headline is that both provider and consumer tests now work in my PactNet branch (which is essentially a rewrite pretty much from scratch now tbh) :tada: There's plenty still to do, like adding V3 matchers (easy), integrating with whatever logging solution lands in core, redoing the sample to http://ASP.Net Core (easy) and sorting the unit tests out (tests for native integration might be fun...).

Oh and message pacts, of course! It should be very natural to add those on now given the new API I've created.

hi all... looks like my mac is set up.. where can i fit into this discussion

You?ll probably have to do more work to actually expose the message pact interface and make it usable - keen to hear your thoughts on this (outside of the proxy approach mentioned/alluded to at https://github.com/pact-foundation/pact-reference/issues/110)

@pact544 first up, thanks - this work was so timely and getting onto the Rust core is a strategic priority for the framework. Let?s step back for a quick moment. There are a few things we should discuss before we go too far, and some flags to raise as we progress (storm!?) into a v3 release: 1. Adam - what are your plans/ambitions going forward? We recently reached out to the community for involvement and have a number of parties interested in driving forward the .NET agenda, so it would be good to know what your plans are and how we can accommodate them / work together 2. For getting the next major Pact .NET out, I suggest we get a project board setup for visibility, discussion, collaboration etc. We should also put it on the main home page that this work is underway (and probably a pinned issue) (https://github.com/pact-foundation/pact-js/projects/3 and https://github.com/pact-foundation/pact-go/projects/2 have them) 3. QA / release process (how do we validate the new interface, FFI boundary, feature tests etc.) 4. As far as getting beta users and feedback, we have a Pactflow POST going out in June - we can do a callout for beta users to get involved, and I?d also like to do a callout to all of our new contributors there 5. Migration guide - we?ll need one of these to help users make the transition 6. Blogs, tutorials .net workshop update - 7. Message support - how do we see that working? :point_down: let?s get a :thread: going on this

for QA/Release, do we want a slightly more formal methodology? Sets of tests for critical and not critical operations (ie must work every release and have a lower expectation of the non-critical)

Specs need to be formulated with minimal standards that enable integrations like FFI to be exercised with RFC compliance in mind

If the new .NET does not have to look like the current one, perhaps a wrapper to enable quick updating would allow quicker uptake of an upgrade, with a migration strategy so users can assess the size and work over a period of time instead of big banging it

The ultimate goal would be as much automated testing as feasible, with CI/CD quality gates for measured values such as unit test code coverage, pass rates and code smells (eg sonarqube)

In terms of my intentions - my company is very heavily invested in PactNet as pushed by me a number of years ago, and I've been checking in regularly for message-type support. Upon seeing the call for replacement maintainers I asked our Director if I could take a stab at it on work time, so I spent quite a lot of last week almost full time on it (and can spend a lot this coming week also). I'm happy to be a contributor but not sure I can commit to X hours per week or anything like that unless my company allows me to do so on work time. I was kinda planning to discuss that with them in the near future, and I can see a good case for allowing me (and others at my company) to help out. I think the alternative would be that we dropped PactNet entirely and went with a very different approach as it's a risk relying heavily on an open source project with no maintainer, so I can see the talks generally going well.

In terms of migrating users over to a Rust-backed version - I mean, effectively this is a complete rewrite at the moment for 2 key reasons: 1. The semantics of the mock server have changed so much (now it's set up interactions then start it vs. old way of starting then setting up/tearing down interactions as you go) that people are going to have to rewrite their consumer tests pretty much no matter what. I haven't tried it obviously, but I think some kind of compatibility wrapper is probably a non-starter. 2. Some of the existing API for PactNet just wouldn't be compatible with some v3 stuff. There are too many things of type `object` whereas all the Rust backend expects nicely split out strings. For example, query string params are now very different. Unfortunately, I think it looks like a "big bang" from where I'm sitting, albeit a pretty easy transition that should be quite easy to write a migration guide for.

On point 1 above - I'd really urge us to reconsider that approach. I know we said it makes the mock server more efficient, but in my testing it's made performance much worse. Each consumer test now takes ~3s on my very fast machine and you're likely to have dozens of them. I haven't done any profiling to find out why but I'd put good money on it being the mock server starting and stopping over and over for each interaction. It could also be that the FFI is very fine-grained with lots of calls, where FFI is known to be quite slow, but I'd say that's unlikely to be contributing seconds of latency.

On QA - I have absolutely no idea short of beta testing. Obviously you'd have unit/integration tests in there, but writing those for interop code sounds like a real nightmare. You can't inspect the internal state of the other end of the FFI boundary so you'd basically have to write proper consumer tests in order to validate and check the resultant pact file afterwards.

On release process - obviously it would be a breaking change so we bump major version, and we also need to distribute the FFI libs on an OS-specific way. I think you can use NuGet for this to bundle native deps and then it restores the correct one at build time via OS detection, but we'd need to check that

On message support - I've not given too much thought to how you have an equivalent "mock server" given you don't know which message queue the client is using. I was hoping to steal ideas from other Pact libraries for that :smile: The actual API inside PactNet itself is pretty straightforward though I think once the message queue tech is abstracted

Oh, another thing for QA - we're going to have to do plenty of cross-platform testing now that we're entirely reliant on FFI. There are probably tons of gotchas (even stuff like the library having a different name/extension on different platforms)

I had a quick look how `Com-Pact` (an alternative PactNet implementation in pure C#) works for message pacts, and in that you simply supply a `Func<string, object>` which will be called for each consumer/provider interaction which is expected to work like the real message queue. I think that's a good approach and it abstracts away the underlying MQ technology from PactNet.

sounds very similar to the other approaches

FYI see the diagrams here for the Ruby implementation: https://github.com/pact-foundation/pact-message-demo

This is how Pact Go \ JS \ PHP \ Python do it

We talked about passing a function to the FFI to invoke, but the thinking was that may be problematic - e.g. async/promises etc.

so it currently works like the verifier, needing an HTTP endpoint to call. If the framework spins this up, it can simply register those `Func<string, string>`and the framework can map the incoming message (via the `description` ) to the correct registered function

this was what I was alludinsg to with provider states. Basically the same mechanism

Hi @pact544 it actually is. I've done the change on the pact-net side but was stuck because I didn't have the rust system implemented :slightly_smiling_face:

I might take your branch and simply plug my integration test / code to see if it works

Hi evereone. Thanks @pact544 on all the work with the Rust integration! That's going to prove useful! I will be focused on the messaging part but have to really understand the difference with the Rust integration. As far as pact messages go, I'm not 100% sold on the approach with a proxy server that simulates an HTTP request. That would mean for each interaction model we would need to have a specific route... maybe look at the java approach and have a build-in verification for the messages. Regardless, I stand with my 4 hours contribution per week. in the next few weeks.

@pact544 on our internal lib, we created a fixture class that takes care of the port, clearing interactions, the mock service, etc. That could be a way to "factorize" the work you do initializing each test.

Yeah cool. The way I saw it working was adding a method onto `IPactBuilder` that returns an `IMessageBuilder` which mirrors the existing `UponReceiving` which returns an `IRequestBuilder`. That way the API means you can't get it wrong, so like: ```public interface IPactBuilder { IRequestBuilder UponReceiving(string description); IMessageBuilder WhenReceiving(...); // or whatever the method is called }```

The WhenReceiving is not bad. That would allow a new builder to implicitly add the provider state with the description. (on my end, the provider state is mandatory to simulate the message on the provider side) The IMessageBuilder will also need to Verify a certain message is being sent without any problem.

`ExpectsToReceive` would be more consistent with the other languages, FWIW

That's the one :thumbsup: Couldn't remember the term used

@matt.fellows Do you see another interaction model (in the upcoming PACT specs)? We would need to create a builder for each one in that case. Not a bad idea.

> I will be focused on the messaging part but have to really understand the difference with the Rust integration. Awesome - hopefully your work does translate nicely! > As far as pact messages go, I?m not 100% sold on the approach with a proxy server that simulates an HTTP request. I?m not sure I understand. There is no simulation of the HTTP request with message pact, because in message pact it doesn?t model an HTTP req/res cycle. The HTTP proxy is simply an implementation detail for *message producer tests* in order to communicate to the message pact FFI interface, which is essentially a call to a verifier CLI - see https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_verifier_cli#verifying-message-pacts (it needs to communicate to an HTTP interface, something I don?t think we should expose to an end user wanting to test that their function is able to produce the correct message for say, a kafka or SNS topic) > That would mean for each interaction model we would need to have a specific route... maybe look at the java approach and have a build-in verification for the messages. Java does it all in proc, but it is not using the FFI interface. The luxury of Ron being the core maintainer of both JVM and Rust means he?s happy to do that work twice :wink: > Regardless, I stand with my 4 hours contribution per week. in the next few weeks. Amazing - thanks!

Yeah I think it's best doing it that way because then all the 'sub-operations' are grouped together on the specific builder

Like that means you can't accidentally do a `WithQuery` on a message interaction and stuff

Got it @matt.fellows in any way, to me the first step is to have a consumer pact with a message using the rust and the provider side will follow. Thanks for the clarification

and each interaction model is served by the IPactBuilder but work independently. Agreed!

I'd also had a thought about how to handle different spec versions and thought we probably want like an `IPactBuilderV2` and `IPactBuilderV3` to support different things you can do between specs. For example, v3 supports multiple provider states and provider state params, but v2 doesn't. If you put `GivenWithParam` on `IRequestBuilder` then you've got to validate every call to check if the spec supports it. I'd rather the API means you just can't get it wrong

Indeed

I?m really not wedded to implementation, and I?m an outsider as far as .NET is concerned. I have to trust that you know what is ideal for .NET library consumers

I?m mostly here to provide the frameworks overarching goals, help wrangle, coordinate where I see opportunity and connect people

@greg595au?s points around testing are valid, so I would love to encourage us to think about what the testing approach looks like. I think testing the FFI interface directly (from the .NET code base) may not be the best use of time though, and feature level suites that exercise the interface in the ways we need to remain reliable are probably a better approach. This way we prevent breaking API changes at the consumer level, which will help stability, we prevent breaking changes from FFI going out and we also get a nice set of examples we can share with users

We kind of do this in Pact JS. The example projects now get tested as part of the build, so if we change the API in a backwards incompatible way, they will discover it. That was a bit by accident, but going forward we?ll invest in more of those because it turns out they?ve been really handy

yes

to both :stuck_out_tongue:

Yeah I think the PactNet stuff is already like that, with the sample actually containing tests :thumbsup: They just probably need fleshing out a bit more

How are you going to prevent V3 matchers from goinsg into a V2 pact? Presumably you allow essentially any object in the body, which can contain matchers? Can you detect htat at the type layer? (ideal)

I had to resort to reflection in Go, which was a bit shit

It needs a test to actually look what the resultant spec file looks like though as well, which isn't there at the moment. They're samples of how to write consumer tests, but don't actually verify the the resultant pact file is valid or did everything you expected

For example, if `IRequestBuilder.WithQuery` just did nothing, the consumer tests would all pass but the resultant pact file would be wrong. You need tests to make sure it does call the FFI when you call it

I would _love_ to see a feature suite (e.g. in BDD/Cucumber) that specifies the behaviour we?d like to see for _all_ rust implementations

and then implementing that per language is the roadmap to done

@greg595au what do you think about that concept?

Yeah that'd be great, just implementing the steps files per library

> @matt.fellows Do you see another interaction model (in the upcoming PACT specs)? We would need to create a builder for each one in that case. Not a bad idea. yes, v4 introduces a few new things. The main interaction level ones are synchronous messages (1 request <-> * response). There is also plugins coming, but that would probably be a separate interface altogether. See also https://github.com/pact-foundation/pact-specification/tree/version-4/ and https://github.com/pact-foundation/pact-specification/issues/71 It just turned 1, so Ron is about to kill it and close it off.

The rest of it is going to be new matchers, and new annotations for the Pact file (labels, pending tests). HTTP interactions can also be in the same file as the Messages

I've done a lot of BDD in .Net but for anyone that hasn't: https://docs.specflow.org/projects/getting-started/en/latest/index.html

That's basically the only BDD framework, but it's also very good and integrates with VS very nicely

I?ve not done .NET before, but even I?ve heard of it!

Yeah adding v3 matchers to v2 pacts is def problematic because at the moment the request body is just a `dynamic` (and has to be really) which the Rust end translates into the proper rules (which is a very nice feature btw)

I was hoping you had some brilliant idea I could steal for Pact Go, but that makes me feel better

So what I have, is a method that navigates the object that was put in, and errors if it contains a matcher with the wrong specification version

But that might be better off in the rust core, tbh

Com-Pact does it a very different way where you build up the request very rigidly, which I do kinda like but it's also very strict and verbose, like this: ``` .With(Pact.JsonContent.With( Some.String.Named("eventId").LikeGuid("f84fe18f-d871-4dad-9723-65b6dc9b0578"), Some.Object.Named("recipe").With( Some.Element.Named("name").Like("A Recipe"), Some.Element.Named("instructions").Like("Mix it up"), Some.Array.Named("ingredients").InWhichEveryElementIs(ingredient) )))```

The DSL is all here: https://github.com/bartschotten/com-pact#pact-content-dsl

I considered that, but I know how JS and Go get used based on a few years of maintainership, and I didn?t think it would fly (despite have a much stronger type system)

trade offs

Yeah you could do the same in .Net and have like an `IBodyBuilderV2` and `IBodyBuilderV3` with lots of methods for building up the body that were only valid for the specific spec version, but I don't think that would fly with users either. It's very verbose even if it is technically the most correct way

Like ```.WithJsonBody(builder => builder.Object.Like(...))``` and chain those all the way down like Com-Pact does

Hey @matt.fellows we are doing BDD also heavily with Specflow. Our PACT lib actually has some BDD integrated. We could add some for sure. Sharing the Gerkins would be an idea.

I've started filling in unit tests for my branch now, with all the interop stuff abstracted so at least I can prove that everything _should_ call the Rust core properly as long as that one interop class is implemented properly, although obviously that one interop class currently has no tests because they'd be very tricky to write properly. We should definitely do at least one happy path integration test against it though just to make sure.

OK, integration test is there also which fully starts the mock server with a properly setup pact and interaction, calls the mock server, writes the file and verifies the pact contents afterwards, all using the real Rust core library :thumbsup:

That would be ace

https://github.com/adamrodger/pact-net/blob/feature/rust-interop/tests/PactNet.Native.Tests/NativeMockServerTests.cs looks very similar to how I started. Good to see :stuck_out_tongue:

@matt.fellows we can write cucumber style tests in a tech agnostic way. This gives us a lot of flexibility and re-use. @pact544 interested to see what u have in that space. We'll need to agree on the statements but i think we can do that in a few conference sessions

Yeah I was thinking along the lines of ```Feature: Multiple provider states Scenario: v2 pact should error Given a v2 pact between 'consumer' and 'provider' And an interaction named 'v2 multi provider states' When I add the provider state 'test provider state' And I add the provider state 'another provider state' Then I should receive the error 'v2 pacts don't support multiple provider states' Scenario: v3 pact should work Given a v3 pact between 'consumer' and 'provider' And an interaction named 'v3 multi provider states' When I add the provider state 'test provider state' And I add the provider state 'another provider state' Then the interaction should have provider state 'test provider state' And the interaction should have provider state 'another provider state'``` If those were all in a centralised place as the spec files, then each library could simply implement the steps files required to drive it all and we'd have a kind of 'spec compliance' suite which is library-agnostic. That'd be awesome. We'd just have to be careful that the tests themselves weren't written with particular implementations in mind or something because the idiomatic APIs across different languages may make it difficult to fit in with the steps otherwise.

exactly

As an aside, Seb Rose is a big Pact fan - I wonder if we could get him involved in some way?

He also recently got Beth to talk about Pact at an upcoming conference, so perhaps we could ask him to return the favour :stuck_out_tongue:

It's not a bad idea to put the specs as Gerkins based but just a footnote, with specflow, it is quite different from normal integration tests. While it's a good idea, I think we should do it at the end because it can be quite a big code base.

Yeah at the moment I've just got some basic integration tests at both the FFI level and the the 'user API' level to validate that everything works correctly, but they definitely won't be as extensive as the kind of thing I've outlined there. Just simple happy path stuff

One thing they do in pact js I think is to separate the matchers based on specs. We could imagine another way of defining the matching rules for v3 but yeah the problem would be the validation between configuring a v2 pact with v3 matchers...

I've just pushed the change that enables this :thumbsup: So now you specify the version at the point you create the Pact object, and you get a versioned builder back which only lets you do things that are valid for that version: https://github.com/adamrodger/pact-net/blob/feature/rust-interop/tests/PactNet.Native.Tests/PactExtensionsTests.cs#L68-L97

hi @pact544 your cukes is looking good. I concur with a central repo of tests as we ensure the product will have been consistent coverage from a "font of knowledge"

@pact544 Have you ever tried the @ tags? Names are good too, tags enalbe us to control/filter the test suites

Yeah for sure :thumbsup:

Tests in for the verifier as well now, with the sample provider test acting as the integration test at the moment.

I _think_ we're almost at v3 support for request/response now (not messages though obviously, waiting to see what @yann.courtel comes up with). I've added the extra matchers, just need to add the extra v3 request stuff like provider states with params and binary message bodies. Those are all really easy though.

Hey Adam, I think, as I said, that if they tests are good to go and we are compatible with the spec 2.0, we should go ahead and make a pull review first because putting the messages support. What do you think @matt.fellows Just so that we don't put to many things at once. What do you think guys?

Yeah it should have v2 support afaik. I think the only thing missing from v3 support is binary message bodies now. Just going through the spec and making sure

So yeah, missing for full v3 support: ? Matchers for (all very easy): ? Equality ? Null ? Include ? Combining matchers with OR (need to check how the Rust core wants these formatted) ? Generators (propose we don't make that a base req) I can do all of that today no probs. Binary bodies are actually v4 so I don't need to do those after all.

ok sounds good! I will just focus on adding provider states by the API tests for now. The messages will come right after. Shall I push onto your branch directly?

I suppose it's one for @matt.fellows. You can def raise a PR against my fork, but then it's weird that the dev is happening in my fork instead of the main repo :slightly_smiling_face: But then also I don't have push access to the main repo so I guess it has to be there?

Well why not, it's like an intermediary branch :wink: I tried without the Rust support and I have too many things to duplicate unfortunately

All for getting it out and in the hands of people sooner rather than later

those matchers are advanced uses, and are not commonly used across the ecosystem yet anyway

Getting rid of Ruby would be the #1 in and of itself, let alone the other benefits

This is where I need help (maybe @jacek.helper has thoughts on this), but ideally, we have a separate tracking branch for the v3 release and can get it published on Nuget as a beta.

In that case, should we initiate a 4.0.0 version since there are many breaking changes? :slightly_smiling_face:

we then need a plan to maintain the current path in parallel for a period of time

indeed we should

Yeah it'd def be v4.0.0, and could do with some proper review of the codebase as a whole given it's essentially a rewrite

@pact544 I am starting with the sample (API tests) to make sure they work with the V3 Pact builder (they do ^^) and adding the functions one at a time, TDD style. I can stash my work and go from master as soon as the 4.0.0 is created, no problem.

Before we can release a first beta version though we need to sort out packaging up the Rust libs as a NuGet because at the moment they look at a locally compiled version

that's true. Almost forgot

I can def have a go at that as well. The repo still contains all the old scripts for grabbing the Ruby version and stuff, so we should replace all of that also

@matt.fellows I'd tried the bintray link to the released Rust versions and it just gave me a 404 though. Do you know the proper URL?

bintray?

Ahh, they are the C++ artifacts I think

just look at GH releases, that?s where they?re published

bintray is :coffin:

Ah OK, I'll have a think about how best to grab those then. IIRC github supports a "latest" metatag, but it's probably best that we hard-code the version in a script somewhere anyway so it's clear when we upgrade

Oh - do we only support 64bit libraries? I'd expected to see 32bit for Windows/Linux

The test runner in Visual Studio runs as 32bit by default as well (who knows why) so it gives you errors unless you change from the defaults

I believe you can change the target processor for 64. no?

Might need that 32 bit then - currently there is no 32 bit build, but I assume it?s doable

as for the release pinning, I do that in Pact Go. I think it makes sense, because semver etc.

Yeah plus keeping bindings up to date with a moving FFI target, nah thanks :smile:

:point_up:

Right, I'll prioritise getting the native deps bundled up somehow then and we'll see how it goes

Looking for opinions on packing these native deps because there are two options: 1. Like now with PactNet.Windows, PactNet.Linux.x86 etc etc so the user has to install the appropriate package for their OS a. Good - creates small packages b. Bad - it's really annoying when working cross-platform to have to have OS-specific conditionals in your csproj (e.g. you mostly work on Windows but CI runs in Docker/Linux), plus Visual Studio only updates the Windows version when doing nuget upgrades 2. Just build one PactNet.Native package which include all the OS-specific FFI libraries, and then it unpacks the correct one at compile time depending on the OS c. Good - only one thing to install and then it all just works d. Bad - big package (probably around 30MB) Opinions? I think I prefer option 2

I would prefer #2. Indeed, we have our local test on Windows and on the build, it's on a Linux system so more maintenance to do.

The support for multiple parameterized provider state is actually super easy since the rust ffi supports it. I added an API test (in the sample projects) to test the V3 specific features. I think we can add it to your work @pact544. We would leave out only the messaging part for another branch.

Oh, I already did the parameterised provider states, sorry!

haha, it's fine, I got the code base and added the V3 Api tests ^^

Cool, 2 it is

have you got the ?value from provider states? feature implement? Add that to the #TODO

Yann - are you saying you?ve added tests to Adam?s code base already?

I?d go with 2

that?s the new plan with Pact JS

I haven't pushed it yet (not sure I can) because the provider state middleware will have to change to validate it can get the values from them.

The consumer part works fine

nice

we should get you folks push access to the main repo, so you can collaborate

it's not super mandatory since it's not a lib problem but it's on the provider side but it would be nice to have a full API tests for V3 features :slightly_smiling_face:

haha yeah. Although seeing the code base up close, it will be much easier to implement the messaging part now

It also makes the whole thing _so_ much easier to write

Yeah I even put a `TODO` in the code exactly where it needs to go :smile:

Hi guys, Great news that you push forward work on V3. @matt.fellows I am happy to share my thougs/help just feeling a bit lost in this thread. There are number of technical details and questions so I am not sure on where my input can be valuable.

yeah, it moved very quickly from ?hello? to ?here is an example working with FFI?

The current state is there is a working v3 compatible branch using the FFI bindings, the macro level questions are currently - what does a rollout of this look like (e.g. to nuget, branching, testing, beta testing etc.)

I?ve just invited you folks to join the org

So I've got it all packaging up properly. The packed nuget is ~25MB and fully unpacked it would be ~75MB, but it should only unpack the ones you actually need so ~10MB

Awesome!

25mb seems totally reasonable to me.

When you get several hundred MB for a react project, what?s another 35 mb?

What do we think about using a project board to track the work e.g. https://github.com/pact-foundation/pact-net/projects/1?add_cards_query=is%3Aopen

you don?t have to convert them into issues

I?d suggest for big items where we may want a collaborative/review process, we could convert into issues. For smaller tracking, the task itself might be fine

Currently it?s hard to get a ?snapshot? as to where things are at

Yeah we probably need to add x86 at least for Linux if not Windows as well, and maybe the new osx processor also. That's probably double the size

If you like, I can put basic placeholder cards for all of the things at a macro level might need to get done. It doesn?t mean we can?t release a package before then of course

Maybe even MUSL for Linux so it works in Alpine containers

And ARM

:joy:

M1?

Yeah

I think Ron has the musl stuff covered, at least, he has a process to generate musl artifacts - for that exact reason

For now I'll just leave it at x64 but it's just a few lines of copy/paste to add further arch once they're supported

Few thought from me: 1. I think it will be easier to drive a changes and collaborate, especially from the meta level point of view if we have task, issues related to some kind of plan. Like GitHub issues, which can be used also for release notes. It will be also more transparent for others users, what they can expect and in which order 2. In my maybe not pragmatic World I thought that we will do that in two steps: Moving to Rust, adding v3 support. Which will be first that is relative. Moving to Rust itself should be an internal binary change, with still same public interface, we should be able to avoid breaking changes. 3. Although I didn't see a code changes, it looks like a big thing worth to major bum up 4. In terms of supporting two version (not sure if If I chain good understanding ). When we will release new 4.0.0 version, then we should only fixed bug for older one 5. Beta version - very good idea for such change. We just need to think about asserts here e.g. how long, is there anyone which we want to ask directly about test and so on. It will be good to know under which condition we want to promote beta version. 6. I never use term of FFI, but if you think about calling RUST fro c# then we may have invest some time for more narrow compering to end to end, integration tests suit. They will just focus on such integration 7. Branch like 4.0.0 sounds good to me 8. Nuget release, depend on how we want to test it, we may even start with alpha version (`4.0.0-apha001, 4.0.0-apha002`), next beta, and final one. Personally I am using GitVersion for this. I am almost sure that you have think about all of this stuff, so sorry if I didn't add anything new. At least just share my broad understanding.

That?s great Jacek!

I think the beta version for a 4.0.0 sounds reasonable. As far as breaking changes, I think there will be quite a few :smile:

> Moving to Rust itself should be an internal binary change, with still same public interface, we should be able to avoid breaking changes. This particular bit isn't possible unfortunately. The semantics of how the mock server works have changed quite substantially so the old API no longer works

Since the PACT v3 specs are also encapsulating the old specs, it's not that big of a deal to rewrite these parts.

1. Yes I would love this also. Primarily, I can to help drum up beta users and drive adoption. I suggest we use https://github.com/pact-foundation/pact-net/projects/1?add_cards_query=is%3Aopen 2. We?ll probably go down a path similar to that in JS Jacek, but only because I need to give Tim some time to fully appreciate the power of the new interface and changes that migt be required. It?s doable on the provider side, but I just don?t think it is worth it for the consumer. I think a breaking API change is personally OK - at least, if we do a big breaking change, now is the time 3. yep! 4. agree 5. Cool - happy to facilitate and get beta users on (via our many comms channels) 6. Yep. we discussed perhaps some BDD/Cucumber scenaros for this 7. :thumbsup: 8. Sounds good. I?d suggest `4.0.0-alpha+buildversion` because it will be easy to see as a human with an incrementing build number (i.e. when it comes to telling people they can immediately see)

We need to differentiate v2 pact specification support against the current Pact .NET interface. v2 _must_ be supported, but the previous .NET API need not

The version would need to be `4.0.0-alpha.1` instead of `+` because `+` isn't taken into account by SemVer (i.e. 4.0.0-alpha+1 and 4.0.0-alpha+2 are considered equivalent)

yes and getting alpha version could mean more branch and PR which would be easier to add small features

ah yes sorry. that?s exactlyp what we do with Pact JS

I originall had the gitsha above, then decided against but didn?t correct

glad we?re on the same page :laughing:

I?d also highly suggest we follow conventional commits so we can automatically generate release notes

we do it on practically all other Pact repos, and it?s lovely

@pact544 do http://nuget.org still have a problem with proper sorting versions like `4.0.0-alpha.9` and `4.0.0-alpha.12` Internally we are using JFrog artifact On*-*Prem, which has this issue. In this case we may want to consider adding a padding zeros like `4.0.0-alpha.001`

Sorry for JFrog link, That was not intended

Nah nuget supports proper semver2

@pact544 you are awesome :slightly_smiling_face:

@matt.fellows > We?ll probably go down a path similar to that in JS Jacek, but only because I need to give Tim some time to fully appreciate the power of the new interface and changes that migt be required. It?s doable on the provider side, but I just don?t think it is worth it for the consumer. I think a breaking API change is personally OK - at least, if we do a big breaking change, now is the time My motivation was giving users, which do not need V3 better Pact implementation, without a need for adjusting to breaking changes, which maybe costly for them @pact544 > This particular bit isn't possible unfortunately. The semantics of how the mock server works have changed quite substantially so the old API no longer works  By old API you mean old pact-net public API? Could you provide some examples, where you think it will be hard to keep current public API? Do not take me wrong, I do not want to be stubborn on this, I just think that even if we cannot avoid breaking change we should think twice before we adding yet another one. This will allow us to simplify migration steps, gain more new version of pact-net clients, especially if they do not have motivation to use V3.

@matt.fellows the injected values for provider states is a 3.5 specs feature right?

It's kinda a not in a spec feature, i think

But simple to do

Okay I see

You just need to return a hash from a provider state endpoint

@jacek.helper Yeah no probs - so in the old API you start the server in a pre-test setup fixture, then you setup each interaction (which configures the server in real time), verify the interaction (which might fail) and then you clear the interactions at the end of the consumer test so that the next one starts with a "clean" server. i.e. you start the server once and call setup/verify/clear on it many times. The new Rust backend is the opposite way round. First you setup the interaction(s) that you want to perform, then you start the server, verify and shut it down again in each test. So that means in a test suite with 20 interactions you will start and stop a mock server 20 times, whereas previously you'd start it only 1 time and just interact with the same server 20 times. If you try to interact with the Rust server after you've started it, the changes that you make have no effect. It takes a snapshot of the interaction state at the point you create the server and that's it, it's fixed for the lifetime of that server. That means the old API no longer makes any sense - you can't change the server after you've started it and there's no notion of "clear".

In rough psuedo code it's: ```Old Ruby way: [TestFixtureSetUp] public void Setup() { server.Start(); // once at the start before any interactions happen } [TestFixtureTearDown] public void TearDown() { server.Stop(); // once at the end when every interaction finished } [Test] public void Interaction1() { server.UponReceiving(...).WillRespond(...); client.CallServer(); server.Verify(); server.Clear(); // clear the state ready for the next interaction that reuses the same server } [Test] public void Interaction2() { server.UponReceiving(...).WillRespond(...); client.CallServer(); server.Verify(); server.Clear(); } New Rust way: [Test] public void Interaction1() { rust.UponReceiving(...); // setup must be done _before_ you start the server using (var server = rust.StartServer()) // every interaction starts and stops its own server { client.CallServer(); } // at the end of this using block the verify happens and the server shuts down. There is no Clear } [Test] public void Interaction2() { rust.UponReceiving(...); using (var server = rust.StartServer()) { client.CallServer(); } }```

So, yeah, in order to adopt Rust as a backend, even if you tried to make the absolute minimum changes possible, our existing users would already have to rewrite all of their tests for a large breaking change

Secondly, the Rust backend accepts arguments very differently from the Ruby backend (it's much more fine-grained) so you have to make other breaking changes to the way that interactions are set up (specifying headers/query strings/etc). All in all, it's a large breaking change to move to Rust which requires users to rewrite their tests

Thirdly, the way that PactNet is currently distributed is via OS-specific nuget packages which wrap the Ruby dependencies. We can't repurpose those to use Rust because otherwise older versions of PactNet could very well break. The actual NuGets themselves need to change (as in, new names) in order to prevent older pactNet versions from breaking

I've pushed these changes up now. There's a script to run which grabs the Rust deps and puts them in the appropriate folders (replacing a similar script which grabbed the Ruby deps) and then it should all just work

I've created a little sample project to test installing the nuget and it all restores fine and finds the FFI libraries, but there's a really weird problem with the API that I can't quite put my finger on so currently it definitely doesn't work

When you try to write a consumer test it tries to call an `internal` method instead of calling the `public` version of that method, so it gives you an access exception

The request sets up fine but once you call `Willrespond` it throws an exception about trying to call the internal versions

I can probably just rename the internal method and it'll be fine though

Thanks a lot @pact544 that's weird

Nope, this is super weird. It's using the concrete implementation instead of using the interface version of the method call. I think it might only be a problem in Release mode as well :open_mouth: I've renamed the internal versions to have `Internal` at the end and now it just says it can't find it at all: ```$ dotnet run Unhandled exception. Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: 'PactNet.Native.NativeRequestBuilder' does not contain a definition for 'WillRespond' at CallSite.Target(Closure , CallSite , Object ) at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0) at pactnet_test.Program.Main(String[] args) in C:\temp\pactnet-test\Program.cs:line 74 at pactnet_test.Program.<Main>(String[] args)``` I honestly think that's a bug in the .Net Core runtime

It compiles absolutely fine but then fails at runtime :open_mouth: If it was a problem it shouldn't even compile

The WillRespond though is tied to your interface, are you sure it calls the one using the correct abstraction?

Like I say, it wouldn't compile if it wasn't the correct one. It only fails at runtime

Not necessarily, if the call is made at runtime

Look at this really weird hint in Visual Studio though

It thinks its become a dynamic!

where is your example at?

Just in a little local console app to test the nuget restore

Literally just `dotnet new console && dotnet add package PactNet.Native` after I've built the nuget locally, then paste the example in from the integration tests

Compiles fine, blows up at runtime

That shouldn't even be possible

It's strange on my end, the auto-completion doesn't even pick up the WillRespond... even with Resharper

I'll have a play around with it and see what happens

Probably because I've got 2 explicit interface implementations with clashing names

yeah prob

We should prob add to each Request builder the interface they need

but that would be a chaining of the interface...

Like IRequestBuilderV3 : IRequestBuilderV2

Not sure it's the design you intended

You can't do that otherwise as soon as a v3 builder calls a v2 method it'll get back a v2 builder instead of a v3 one

the only probleme I have is with WithJsonBody...

The auto-completion works when I pass a dynamic directly from the test function and not as a dynamic class variable... I don't know what's going on...

https://www.filipekberg.se/2013/01/17/im-using-dynamic-and-unexpectedly-lost-intellisense/ interesting thread

What I got from this is that the line where your dynamic is defined matters, so in your case, maybe add it inside your test instead of an instance variable.

Ah gotcha :thumbsup: So yeah sounds like a .Net runtime bug

Like it doesn't become "undynamic" again

yep, well that might be a limit

the dynamic's intention is to be used dynamically and not "stored" per say. That's what I got from this, but I didn't know it would have consequences like you had at the runtime!

Ha, yep that worked fine!! Literally just moved the variable to be inline instead of in a static field and it now works fine

Great

Phew!!!

Thought I'd seriously fucked up the API somehow then

no, thanks god

Well in that case, enjoy the new nuget support :smile:

haha thanks

I tested the script on my end and it works fine!

Niiiice

We need to get the CI going properly now all the tests work

Compilation is fine, running all tests, there are a few mishap... maybe the dynamic

Especially with the cross-platform GitHub Workflows thing because I can't test on OSX atm

Ahhhh, you know why that is? `mock_server_logs` is on `master` for the FFI library but not in the latest released version so that binding is failing now we've switched over

impossible to find the mock_server_logs

Yeah when I was compiling `master` locally that worked fine, but the latest release doesn't have it

it fails the Api test for the same reason

Needs a new FFI release

well, it looks like just one thing

Maybe Matt or Ron can do it

Nice summary. I was thinking we could wrap the using into a more userfriendly method like Verify(() => client.myAction... )

Well, seeing you need the MockServerUri, it will have to be into a specific fixture class to work.

Still, it's much easier to write the interactions like that

Yeah you can't know the mock server URL ahead of time because you generally use a dynamic port so you need to wait until it's started before you can construct your client

yes, I was just thinking on the end user, using it inside a fixture class which takes care of the instanciation of the server and which port it uses will make the test even easier to write.

I don't know if the lib pact-net is the place to do it though :slightly_smiling_face: prob more on the consumer side

Class fixtures run once before any test runs though (which is impossible because then you can't add interactions to it): https://xunit.net/docs/shared-context

You need to use the ctor/dispose approach

yep, as a custom one you can

but again, that's more of a consumer-side optimization

You need to add the interaction before you start the server though

You literally have to start the server inside each test so that you can set up your interactions before starting it

I still don't think that's the best approach, but that's the way the Rust core is so this is the API you kinda naturally end up with in PactNet

yeah, we will see once we have the version up

I'm off, have a nice day and thank you for the effort today!

No probs dude, have a good evening

I've accepted the invite into the pact-foundation but I'm not sure that actually gives me write access to anything :slightly_smiling_face: How do we want to proceed with getting my changes merged over into a proper branch in the pact-net repo?

has joined #pact-net-development

@pact544 regarding to your pseudo code. That is not how I see this I think I understand your intention, but I still think that it should be possible. In pubic interface there is nothing about starting or stoping so I am not sure if I will expose something like `StartServer` or something similar and make this public concept, it can be just technical details. Below I try to show how I am using currently pact-net: ```[OneTimeSetUp] _pactConfig = new PactConfig      {        SpecificationVersion = PactConfiguration.PactSpecificationVersion,        PactDir = Path.Combine(testBinDirectory, PactConfiguration.PactsDir),        LogDir = Path.Combine(testBinDirectory, PactConfiguration.PactLogsDir),        Outputters = new List<IOutput> { new NUnitPactOutput(Console.Out) }      }; [SetUp]      _pactMockServiceSetUp.MockService.ClearInteractions(); [OneTimeTearDown]      _pactMockServiceSetUp.PactBuilder.Build();      _publisher().Publish();       [Test] MockService        .Given($"Foo")        .UponReceiving($"Bar")        .With(_tfp.CreateValidRequest())        .WillRespondWith(_tfp.CreateSuccessfulResponse(links));        _myCommunicator.CallSomeAction(        .Should()        .BeEquivalentTo(new Invoice("http://dummy"));        _pactMockServiceSetUp.MockService.VerifyInteractions();``` In my example if VerifyInteractions will have this whole stuff with starting and stopping server will works for me. > Thirdly, the way that PactNet is currently distributed is via OS-specific nuget packages which wrap the Ruby dependencies. We can't repurpose those to use Rust because otherwise older versions of PactNet could very well break. The actual NuGets themselves need to change (as in, new names) in order to prevent older pactNet versions from breaking Just to make this clear you talk about `PactNet.Windows` package? If so you have right, which is not perfect in my opinion. I am not sure how it is done in details now. However if I will do that in a past or plan some future changes like this one. I will try to separate public pact-net interface concept form engine realization (ruby, rust) details. Just imagine how cool it will be when we will not have to change public interface when we will move to yet another engine realization under the hood. Or imagine if same pact-net client code can once works with rust and once with ruby. To do that we can change a bit how stuff are set up and allow clients to choice core realization by DI.

Two problem with your example there (if it was using the rust backend): ? at the point you make your client call the server is not started, so it will fail ? you don't know the port of the mock server until after you've started it, so if the verify does the start then how can your client know the port to call? Your client can only be constructed after the mock server has started so that you know its URL. That's not the case with the Ruby version. In Ruby the server starts first in your one time setup so you know the URL straight away, and it's always running so your client can always call it. In terms of not changing the public API when we swap provider backend, I think the changes I've made make that really easy now :+1: I've created a PoC remote backend as well, but it's not implemented yet. We could easily create a Ruby backend as well.

> at the point you make your client call the server is not started, so it will fail You have right. However I am still not convince to expose details behind rust server implementation. I think it should be a way to hide this. > you don't know the port of the mock server until after you've started it, so if the verify does the start then how can your client know the port to call? You want to say that i cannot set up mock uri in advance? Why in Rust implementation I cannot specify a port? It doesn't sounds right to me and it is probably related to Rust. By the way starting some external service and stopping it in each test case separately doesn't look like super thing from resource/performance point of view. Is there any way it can be started once, or at least per test suit?

Sorry if this will sounds badly that is no my intention, I just would like to know why we wan to move to Rust in the first place. Does PactBroker or PactBroker client plan to do the same or they will stay with ruby engine version?

The last thing from me today. What about the last feature, which we have added few weeks ago, https://github.com/pact-foundation/pact-net/pull/277 ? Did you think how these two things can co-exist, since it is hard to imagine that somebody will start and stop remote mock server in each test case.

Yeah, so to answer those I think we can still support the remote server no problems. It's probably best checking the new API on my branch to see how it would be possible, but the internals of how a particular server works are entirely contained within the server's own nuget, so you don't tell the server to start or stop. In terms of starting the mock server only once and sharing it, it's not possible. I implemented it that way at first and spent two days scratching my head before I worked out it's impossible. I looked through the Rust source code and found it takes a snapshot of the state at the point it starts so you can't start it before you've set up your interactions. @uglyog and @matt.fellows advised that the approach taken in all the other language integrations is to start and stop the server for each test, so I've mirrored that on the new PactNet API. That's the only way the Rust version can work at the moment.

> Secondly, the Rust backend accepts arguments very differently from the Ruby backend (it?s much more fine-grained) so you have to make other breaking changes to the way that interactions are set up (specifying headers/query strings/etc). All in all, it?s a large breaking change to move to Rust which requires users to rewrite their tests It?s probably the way .NET works, but in Pact Go, I was able to swap out Ruby with Rust without any breaking changes. I chose to make a few breaking changes simply because I think the interface is made clearer. The ?verify? step always accepted a function that was given a context (i.e. the mock server details). So at the least, that would have needed to change for .NET

> Yeah, so to answer those I think we can still support the remote server no problems. It?s probably best checking the new API on my branch to see how it would be possible, but the internals of how a particular server works are entirely contained within the server?s own nuget, so you don?t tell the server to start or stop. cool!

> In terms of starting the mock server only once and sharing it, it?s not possible. I implemented it that way at first and spent two days scratching my head before I worked out it?s impossible. I looked through the Rust source code and found it takes a snapshot of the state at the point it starts so you can?t start it before you?ve set up your interactions. If that becomes a performance issue that we can?t get to the bottom of, i?m sure we?ll find a way to support the stateful server (or something similar)

I?ll add you to the repo, I think the invite has to be accepted first

done

I've thought about that performance issue that I'd noticed and I'm now suspicious it's not the Rust core that's the problem. I'm not really seeing a performance problem in my integration tests which just go direct to the interop code, but I am seeing it when I run the sample consumer tests. However, the thing that's definitely made me think it's more the .Net side is that the consumer tests example also compiles really slowly (seemingly for no reason, it barely does anything)

ok that?s good to know

I just wrapped the node test in a loop that runs the full cycle 500 times, and it runs in sub 3s > ? pact-js git:(spike/ffi-provider) ? time node src/native/test.js > node src/native/test.js 2.11s user 0.29s system 98% cpu 2.423 total > ? pact-js git:(spike/ffi-provider) ?

@pact544 thanks for details. Could you share your branch name, maybe when I feel better I will take a look and share some constructive thoughts.

I've created a draft PR against the proper pact-net repo with my work so far, and written up some of the rationale of the new design within it: https://github.com/pact-foundation/pact-net/pull/297 Please review, and then we can merge it (to the new `feature/4.0.0` branch) to use a base going forwards

@jacek.helper - Just raised the whole thing as a draft PR here: https://github.com/pact-foundation/pact-net/pull/297

Definitely worth changing the setting to hide whitespace changes :open_mouth:

I?m wondering that because the change is so big, the best first step might be to get it merged into a branch so everyone can contribute from there. otherwise I fear the conversation will quickly convert to bikeshedding

But, what a way to end a week (well, for those of us in the future :stuck_out_tongue: )

Ha, thank you :smile:

Yeah I thought the same. It could get absolutely massive and end up stalling otherwise. Didn't want to just yeet it in the main repo though :smile:

Probably just best to review for at least any "omg, def don't do that" changes :smile:

Yes, that's what we agreed on. The message part and the remote mock server is going to be another big chunk of code :slightly_smiling_face:

OK, shall we just merge it then?

Let's do the code review then

It's on a feature branch anyway, not direct onto `master`

I hope @pact544you had time to have some breaks at the pace you were going XD

So yeah cool, if you can give it the once over for any obvious big problems and we can merge it as a base to work on going forwards

yep, the few things I would do it before the merge 1. Split the interfaces into separate files. Maybe do some folder reorganization, like with functional names, Request / Builder / etc. 2. Small code cleanup feature like organizing the usings 3. Use the simpler using declaration (in the tests) introduced in the latest c# version 4. I don't know how you feel about naming convention for the class variable with or without '_' which will allow you not to explicitly have 'this' everywhere. Mostly what I'd call cosmetic changes :wink: For the rest, it's still an alpha version so we can reorganize things later on.

> Split the interfaces into separate files. Maybe do some folder reorganization, like with functional names, Request / Builder / etc. I didn't do this purely because it would make all the imports annoying for the end user. They'd have to import like 5 namespaces just to run a single consumer test

> Small code cleanup feature like organizing the usings Do you have an examples of that one? I have an on-save trigger to sort/remove usings so they should all be correct just by default :smile:

I see. I mean, it's just on Visual Studio, you right-click on your solution and do a code cleanup, just to avoid anything super obvious ^^ let the IDE do the work.

Or maybe it's just my resharper complaining hehe. It can be annoying lol

Just done the cleanup and pushed. It only really trimmed a bit of whitespace here and there though :smile:

Sounds like a major breaking change ^^

Not another one :joy:

I needed to get it done this week. The permission to work on it basically full time was only for 2 weeks from my boss and that ends today :open_mouth: Then I'm on vacation Mon-Fri next week, but I'll check in here occassionally

ah ok! Sounds good.

In this case, let's have it merge asap and we could go from the feature branch

Cool, I'll merge now if the comments are more organisation/cosmetic that we can always sort easily later

absolutely

Would you be able to put a quick comments on the PR just so it doesn't look like I'm merging without any review? :smile:

Even just an "I approve" :smile:

can you link the PR plz? No Problem :)

all good

I put the remaining comments so we don't forget them :wink:

I'll present your work to my team to see if they have comments also. We will go from the 4.0.0 feature branch then. Very nice job!

Done :thumbsup:

Now I'll fix the CI

Strange CI problem. looks like a ps script is not there

Yeah it'll be looking for the script to grab the Ruby libs and stuff

I'll have a look at moving it to GitHub Actions so we get better decoration, and then we can also run the CI on OSX

ah ok, indeed

We will need to also separate the Interop class into its own file into prob a MockServer folder for future maintenance. I prefer functional folder organization rather than purely technical.

That one was deliberately a private inner class so that the outer class could deal with the weird concerns of interop (like wrangling `IntPtr` objects to and from strings)

I see, accessibility over maintenance. I can understand why you saw it that way

Bah, I've got the cross-platform CI going on Windows/Mac/Linux but unfortunately the provider sample is .Net Framework only so it won't build on Linux/Mac. That needs converting to .Net Core really because it demonstrates using it with legacy http://ASP.Net instead of modern http://ASP.Net Core. I think a Core example would be far more useful

Raised a draft PR for converting the sample from ASP .Net Legacy and .Net Framework (Windows only) to ASP .Net Core and .Net Core 5 (cross-platform). At the moment it's failing but because there's still no way to get logs out of the verifier FFI I'm not really sure why...? I imagine it's something do with auth or something. I can curl the API via `curl` and it looks OK so dunno what's wrong. https://github.com/pact-foundation/pact-net/pull/298

Hey everyone, so I started in the message integration but I am a bit stuck on how the different method of the FFI should be called. We have a new_message_pact and a new_message method in the FFI on the pact mock server lib. I'm assuming the first to be called to be the new_message_pact but then when I want to specify the version with the with_specification method, it expects a PactHandle not a MessagePactHandle. @uglyog @matt.fellows Some questions: 1. do we need to call the with_specification method in case of a message creation? (prob not) 2. Is this workflow correct a. Call the new_message_pact method to get the handle of the pact message b. Call the new_message method with the previously created pact message handle c. Call any of the method that takes a message handle in parameters (such as message_expects_to_receive or message_given) d. Finally call the write_message_pact_file with the pact message handle (not the message handle) to create the final pact file Thank you!

Yep that workflow sounds right to me. It's the same as the request/response message flow except that has PactHandle and InteractionHandle instead of MessagePactHandle and MessageHandle

PR to get CI working with cross-platform build and test for Windows, Linux and Mac: https://github.com/pact-foundation/pact-net/pull/299

The performance problems I've seen appear to only be on Windows, and potentially even only on my work laptop. It has some crazy security software on it so I guarantee it's that. The consumer tests take ~3s each on my work laptop, but on my personal laptop running Ubuntu 20.04 they run in <200ms total :open_mouth: Lightning fast. I think we can conclude that there's no performance problems stopping and start the mock server for each test. On average we're talking ~20-30ms per test on Linux

but yes, what you said Yann

`with_specification` is only needed if you want to change the default, which is V3

hi everyone.. sorry I have been out of this for a bit and have some catching up to do, have we got a common code repo/branch.

is anyone opposed to me approving/releasing Adams Replace AppVeyor CI?

:point_up: belay that = we appear to be on Feature/4.0.0

I'm happy as long as you're happy :+1: We probably need to decide how we're doing contributions and stuff. Like I assume it's not ok to merge stuff before it's been reviewed and we're gonna follow a PR model. There aren't many of us though so getting reviews may be a bit tricky.

Yeah we can rename that if we want, that's just the name a came up with for a start. Didn't want to merge to master given it was still a work in progress at the time (well, still is I guess)

would a round robin approach help?

Let's aim for a single thumbs up into that working branch. Releases/master we can talk about in due course

At this stage, high velocity decision making should be the priority - I know that contributions/focus/time is very much dependent on things outside of our control, so let's capitalise on the energy while we can

The earlier we can get into the hands of early adopters for feedback the better

Yep sounds good to me. Try and get some PRs in and turn them round as fast as we can into the 4.0 branch

Shared understanding is also important though so we can get some continuity

Next thing I think is getting the CI to build alpha releases or something so we can get people testing. The whole thing should now work on all OSs, and it's not a big job to get the artifacts building properly

I?ve just added a branch protection rule to enforce the above. Let?s see how it goes

On any PR if you want to review, head to ?files changed?, hit ?review changes? and add your review. It won?t be mergeable until at least 1 reviewer approves

It also will require any conversations (i.e. feedback with requests) to be resolved

agree,, we can deal with all this over the coming days.. btw - noice progress

@pact544 I tried to take a look on your changes, share some thoughts, but I cannot build solution. I am ending with following error ```Severity Code Description Project File Line Suppression StateError MSB3030 Could not copy the file "pact-net\build\windows\x86_64\pact_mock_server_ffi.dll" because it was not found. PactNet.Native C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 4964``` I can only suspect that it is has something to do with `download-native-libs.sh` . Do you expecting people do fire this before building solution? Is it a temporary solution? Sorry if I missed some of your previous info about this.

Rust integration / v2.x.x project board https://github.com/pact-foundation/pact-net/projects/1

Yeah so you'll need to run that to pull down the required dependencies (the Ruby version required a script also). The CI does it automatically and we can always add a targets file to do it

Well, maybe I am wrong, but I did couple of code reviews and I never have to run by hand any script. Maybe you can consider packing these dlls into nuget packages or at least run your script as a part of build process?

Yeah like I say, the CI does it already and we could add a targets file to automate it locally

Do you mean v4?

Yes.

Awesome, I pinned it too

(v2.x.x is the golang next major)

Ok. Will it be listed as nuget dependency ? Do not take me wrong It definitely can work, but it would be problematic in some cases as well. For instance I am working for enterprise where each dependency has to be approved in advance. As part of this proces usually nugts with not transparent dependencies, not explicitly listed as project are rejected. Even if it will be accepted it must goes to our nuget repo in this case jfrog artifactory. Now all our Devs envs and CI are only based on it, cannot download additional external deps. So for case like this it I think it will be much batter if this dependencies will be manage by nuget with proper approach to version especially when we already have DLLs. Otherwise Devs in company like my will not be able to use it, unless I am missing something.

Yes the native deps are bundled in to the PactNet.Native nuget

Hmm, I am feel a bit lost here. Is there any description of your new approach to project organization, packages and etc (I have through this one https://github.com/pact-foundation/pact-net/pull/297)? It will help in my case. If there will PactNet.Native package then I think it will work in above case. Just two questions: 1. Should script `Publish-StandaloneCore-Releases.ps1` works? It looks like it is missing PactNet.Windows.nuspec 2. How you see `PactNet.Native` package? What if for some reason we will decide to add or move to different core? Did you think maybe a more dedicated name like `PactNet.Native.Rust` ?

My last question for today. I see that for some reason you have decide to bundle all dependencies together. I think i go through discussion on this, seen arguments about size and simplicity in some cases, but didn't spot arguments or scenario when someone will only use single os from start to end. That is not about size itself but about binaries which shouldn't be there. Maybe we could keep your bundled packge `PactNet.Native` but also add dedicated per OS, liek it was previously?

Yeah I discussed that with the maintainers of other languages before I did it and we discussed the options. We decided the simple approach with everything embedded was the best approach. There's a thread in the channel about it where we decided that. If you don't want the deps for other OSs unpacked then you can build with a runtime identifier and it'll only unpack the required one, like `dotnet build -r win-x64`, or add a runtime identifier to your csproj file so you don't have to type that each time.

Unfortunately it's not just my work laptop. My own laptop (the one that runs the consumer tests in ~150ms in Linux) takes 12s to run the same tests on Windows on the same hardware. There's definitely some kind of performance problem which only affects Windows to do with the consumer tests. The provider tests take <1ms though :open_mouth: :zap:

I've updated the PR to also produce alpha nugets when code is merged to the 4.0.0 branch

PR for verifying SHA sums of native artifacts when restoring: https://github.com/pact-foundation/pact-net/pull/300

Argh the file paths in the downloaded checksums aren't correct so I've done a bit of `sed` to put the right names in there, but it doesn't work on OSX. That's why the cross platform CI is good though at least :+1:

@uglyog I see. I made an additional test without the with specification and indeed, the message has the same form. The issue will come if we need to specify a future version for the messages. The with specification will need to accept the MessagePactHandle. Thank you for the clarification! @matt.fellows I now need to "verify" the sending of the message to the code base is working. In your example, you actually didn't do it, right? This is your comment I assume. How could we enforce the verification of the message, though?

so the flow is actually this: 1. Call the new_message_pact method to get the handle of the pact message 2. Call the new_message method with the previously created pact message handle 3. Call any of the method that takes a message handle in parameters (such as message_expects_to_receive or message_given) 4. Call `reify` to get back the message body and provider states, with the matching rules etc. removed 5. Invoke the actual function that should handle the message, passing the message and config 6. Only if (5) does not fail (whatever is idiomatic for .NET) then you move to (&) 7. Finally call the write_message_pact_file with the pact message handle (not the message handle) to create the final pact file

so basically, you need to invoke the function that should receive the payload, and check if it passed/failed

There is no need for the rust side to do this bit, because there is nothing it can really do

make sense?

Yep, that's the workflow I add in mind

:ok_hand:

see also https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mockserver/message_server_test.go#L41

My question was can we enforce the verification? As in, adding a Verify method fo the builder for instance?

that?s what I do

see https://github.com/pact-foundation/pact-go/blob/2.x.x/examples/consumer_test.go#L151-L182

line 178 invokes the function here: https://github.com/pact-foundation/pact-go/blob/2.x.x/examples/consumer_test.go#L223-L225

ok, I see in the last example :slightly_smiling_face:

let me know if you have any questions

I?m really keen to see the interface you come up with

I'm going to create a branch today, specific to the messaging

Are there any alpha NuGets yet? I don't see anything at https://www.nuget.org/packages/PactNet.Windows

At the moment I've added alpha nugets to the CI pipeline only

Hey guys i will e avail tomorrow night fr 2 hrs. 7pm to 9pm. Time to get our heads around how we setup gherkin the way we think we can

ha, gotta love the minor differences between bsd/gnu

One of the first things when I get a mac, is to add the gnu tools

not sure what happens when I get to M1 though

That?d be great. What?s a good starting point? maybe scratch together a few shapes to the gherkin?

Start with thw way a common repo is set up and a standarfised way to pull into the projects

After that we look at our testing needs and develop skeletons for each given when then

In specflow (BDD test in .NET) I haven't tried to grab Gherkins from a remote location or a relative path. What I am afraid of is that Specflow does some work to auto-generate an intermediary code file that does the execution of the test therefore I am not sure having a remote Gherkins is even possible. I'll investigate on my end and let you know quickly.

One thing that would be nice is to integrate Living doc with Specflow to see the state of the integration test at the CI.

I didn?t make it clear earlier by the way that I can?t make tonight

but I think a good starting point is getting a working artifact that can be collaborated on.

Sounds like a good place to start @matt.fellows. I investigated with our teams and the easier will be to embark the new scenarios as we develop the feature in each language from the centralized repo. It's not that difficult ;)

Yep, we don?t need to do it all at once. Any starting point we can build from this experience will be really valuable for others

Before we go too far it will be good to think on: 1. Testing strategy. What kind of test we would like to introduce, how they related each other. Few years ago I have been inspired by this article https://martinfowler.com/articles/microservice-testing/ . Although there is microservices concept involve, there are generic approaches, which IMHO suits to many different scenarios. 2. What kind of test type we want to represent by gherkin tests. End to end, component or integration. I am using gherkin tests mostly for component, leaving integration an unit tests for testing framework like Nunit. In this project I am mostly missing integration tests with core engine, which now will be mean Rust.

hey @jacek.helper, while we could potentially use gherkin across the board, there are situations where gherkin is seen as "getting in the way". Dev's at Platform engineering have a divided opinion about gherkin on unit testing

My view is that these BDD scenarios are something we could reuse as features tests across libraries to say "they've implemented Pact" and also to show the gaps. It would literally be able to be translated into a roadmap

Within Pact .NET we should use whatever makes sense for the project. We don't use cucumber elsewhere, for reference

yep - i believe we are looking to deomonstrate the Pact specifications

hich sort of sounds like E2E

@matt.fellows the gherkin statements would provide the specification for the non-cukes implementations

@greg595au I am not sure if I get fully your point. My intention is not promote gherkin as unit tests. If we want to use across libraries, fine but then it will not be better if this will not depend on engine implentation? Stub engine itself. So component tests instead of end to end. As I have mention few days ago the most missing part from my point are integration tests for engine. I would suggest to add gherkin tests, which stubs engine client classes and integration tests, which will start from the same classes. That is how we could have nice tests approach.

@jacek.helper i think we have similar thoughts here, in my point above, the team of nearly 400 devs can't agree on cucumber

so what I am aming for is - where to store the tech agnositc gherkin features

how to bring them into a project (that wants to use them)

Make sense

i don't feel comfortable with forcing the project to adopt, because it will be a workload they might not be able to do

on a completely unrelated note - had my covid shot yesterday started feeling a but stiff today

Unit Tests - leave them in native form, there are tools that tell us coverage

Component and Integration tests seem suited to a gherkin approach

we need to map them to the Pact Spec (and they become the acceptance criteria)

which dovetails with @matt.fellows that they would enable road map to be generated

Any thoughts from @pact544 @jacek.helper @matt.fellows

Will try and respond later. From memory, Adam says he's off on holidays for a week or so.

thanks matt... i'll create a couple of ideas on the location/how tonight

@jacek.helper I like Martin Fowlers work - i often refer to it myself

I am just after covid and during week long holiday :) . I share my thought later on :slightly_smiling_face:

no worries jacek - i'll put up a diagram to cover the basic high level ideas (where/how) we'll circle back on the test stratgey and what fits best :slightly_smiling_face:

High Level Where/How for Specs to Features and then to language specific

i am getting tired, off while I can still stand....

night everyone

Yep I like the idea of a common gherkin description of the spec demonstrating what that spec can do and also how it's limited. I think you end up in an awkward situation though because the spec doesn't cover a number of things and they'll be implementation specific. For example, V2 doesn't support multiple provider states, but if the implementation allows me to try it (i.e. I can call Given twice) then am I supposed to get an error or does the second overwrite the first? The spec doesn't say, so this is an implementation detail and could vary between languages. At first I'd describe only the positive tests, because the negative tests aren't really covered by the spec. For what it's worth, the Rust implementation overwrites instead is giving an error I think.

ah! I?ve heard it can do that, hopefully won?t be too bad!

> Yep I like the idea of a common gherkin description of the spec demonstrating what that spec can do and also how it?s limited. Excellent

There has always been a bit of a gap between ?the spec? and ?what each language actually does?

The spec doesn?t cover certain features. E.g. provider injected values isn?t documented in the spec, but is a feature that is supported

(that might actually just be a spec coverage problem, btw)

but the functional behaviour of each library may change, and that is probably OK - in many cases, that is because each language itself is different and what is idiomatic for one is a terrible experience for another (this tends to be true of type safe and compiled languages vs dynamic languages)

so we should look to find the scenarios and features that are important and common to all, and have those in the Feature spec

Woke up this morning and stiffness is gone.. so i am not expecting to experience anything new now

great to hear!!

Hi everyone, I would hold off on the Gherkins for now until we have a stable 4.0.0 version. Let's not forget it will be a shared repo for all the languages so all contributors across all the different languages will have to agree on this. Also, as I help teams on a daily basis with the different level of tests, the BDD tests in Specflow are quite big to implement and costly to maintain. While it's a great idea, it is IMHO, an overkill for the moment given many constraints : 1. It is a library, therefore we would just be doing a code testing and lose one of the main advantage of specflow (integration microservice engine) 2. How we would copy the Gherkins over to the project to have it always synchronized is something to be seen (a copy/paste is the likely options) For the moment, nothing stops us from adding more integration tests using the classical approach. The more integration tests we will have, the easier it will be to move over to Specflow. All the best :slightly_smiling_face: (Sorry, I was a bit busy this week and saw the messages only today)

I think the gherkin stuff would have to be in a separate repo (although we could start it in one of the language repos to prove it first then split it out after). We'd probably need either a branch per spec version like the spec repo is, or liberal use of tagging or something. In terms of importing them, you'd either want to download them during CI or something, or have a git submodule

hi @pact544 that is the gist of my diagram - isolation of the generic spec gherkin from implementation. That would provide high level guidance on specs and allow language differences (to the most part) to be sorted at implemenation time. This does lead to the situation where there will be semantic and specific language requirements. But as a start using positive tests: ? Common Spec Given When Then ? RFC compliance tests Then we start to implement more, as @jacek.helper pointed out, we need to map our test strategy to enable sensible and adoptable testing approach across http://Pact.io

(PS - i had to replace my good machines HDD - seems its had enough)

I wonder how we actually do it from a practical perspective though. For example, we'd write tests for spec v4 but they'd currently fail for PactNet as it only supports v3. Or we'd write v3 message tests which would currently fail. That means they can't run as part of CI otherwise they'd always fail. Tests that aren't run as part of CI aren't particularly useful, and neither are tests that always fail. I'm really not sure how each language declares the tests that _should_ pass so that they can run in CI and find regressions. It's like each language needs to provide its own set of ignores, but that can't be in the central gherkin repo obviously, so I'm not sure how they do that.

we have a few choices on managing that angle. Branching, folders or tags

tags can become unmanagable, branches isolate V3 from V4 specs nicely

folders are great but then we have a bunch of tests that are not implemented

Branch/tag sounds too cumbersome to me. That would mean you can't update to that branch/tag until you are fully compliant with every test in there. I'm not sure folders works either - how would you tell it to only run certain folders?

we can force cucumber to filter to folders

I've never done that for SpecFlow before. Are you sure that's possible?

i am not a fan of folders, but we need to consider all possibilites and narrow down most suitable

@pact544 like this way

That's only one base folder though. I'm not sure you could organise the folders sufficiently hierarchically that you can opt in and out of tests. Plus that's the CLI runner, which doesn't apply in Visual Studio or `dotnet test`

and by

So you'd have to do this basically: https://docs.specflow.org/projects/specflow/en/latest/Execution/Executing-Specific-Scenarios.html But there'd have to be so many tags that it would be really awkward to write those filters. They'd end up huge and it would be very tricky to manage them in the central repo for all languages

have you got a picture in your mind of exactly what we need tag wise?

I've not, but that's kinda the problem I think. In my mind we're going to need a lot of tags because different languages have different levels of support so it's not as simple as just tagging the spec version or whatever. You need to tag the 'sub features' of each spec. Just like how PactNet currently supports v3 but not in full - it doesn't support message pacts and it doesn't support combining multiple matchers in request/response pacts. Those two features would need their own tags so PactNet can ignore them but other languages don't.

can we have a larger group discussion (maybe teams or other meeting) so we can get a picture of this laid down to inform us how complex this might get

Then your filter is like `v3 & !(message | multipleMatchers | ...)`

@yann.courtel @jacek.helper @pact544 @uglyog @matt.fellows When is a good time to schedule in a discussion so we can map out folder/branching/tagging/filtering so we can make good engineering decisions about the way forward with the next steps

@pact544 i concur that we are going to have complexities and possible issues to nut out. Would you be up for a larger team chat to flesh out a map that shows/demonstrates where the issues (and future gotchas) lye.

Tuesday/Thursday nights next week work for me, which would be Monday morning EU

having a rough couple of weeks Greg!

only the machine

Tuesday works for me for since it's European time, we will have to come up with a specific time? :slightly_smiling_face:

I think @greg595au the first option that comes up in my mind is to not block on the BDD tests. The best approach I see at the moment is to let the languages import the BDD scenarios manually from the repository and add them to their BDD test project. that way we can see which feature is develop for which language. The filtering approach sounds too complex. We can talk about it though next time we meet.

has joined #pact-net-development

@yann.courtel do you mean like this diagram? https://files.slack.com/files-pri/T5F60FXSQ-F024DK0JUMB/screen_shot_2021-06-09_at_8.42.25_pm.png

Where Pact Specs are our wiki (by version)

No I have absolutely no problem with your diagram, I'm talking about the actual implementation. How we can achieve that in Specflow and if it's not too complicated at first. The filter / branch approach.

I agree having scenarios in Gherkins could be a great idea to vehiculate the PACT specs but the process of importing them in each language needs to be reviewed thoroughly. We don't want to add unnecessary complexity :)

One thing that often happens is we see complexity because that is where our minds are.. I think tags might need to be thought of in a more streamlined way. But I will leave that till we convene for a conversation where we can trial the ideas on paper

My parting thoughts, if we fixate on what can't be done and over look simplifications, we'll be ineffective influencing uptake in other languages as they progress.

I understand your point. Although my thoughts were coming out of researching a way to do it, not just posturing. I see the potential of such a repository.

Hi everyone, I created a branch for the messaging support that is pulled from the feature/4.0.0 branch. https://github.com/pact-foundation/pact-net/tree/feature/messaging-support This will be the main branch to add functionalities for the messaging according to the PACT specs 3.0. I did most of the consumer part and will work on the provider side today. Any feedback will be welcome.

Niiiice. I'll try and take a look at some point

I'm still not convinced about the Consumer verification of the message. It's done by the MessageReify method on the RUST (Verify<T> of the NativeMessageBuilder) that returns an object with a property Contents that has the message without the matchers. There is a double deserialization... therefore I'm not sold on it just yet ^^

Another thing I'm not convinced of is the NativeMockServer that has all the methods for all the interaction model. Including the message support. Maybe we could better separate the Interop methods (class Interop as internal instead of private) and add a NativeHttpMockServer and a NativeMessageMockServer which uses only part of the Interop methods...

Yep, the NativePactMessageBuilder should absolutely NOT have a dependance to IMockServer as it could use the method CreateMockServerForPact and that is not conceivable. I will have a new IMessageMockServer to encapsulate just what we need.

Yeah the class can just implement both interfaces, but pass round as interface to prevent being able to call the wrong one

Yeah right! an IHttpMockServer and IMessageMockServer and each builder will have the right abstraction. Good idea and less changes!

Yeah that's how the v2/v3 builder works. Two separate interfaces so you can't get it wrong, but `NativeMessageBuilder` just implements both to reduce code duplication

Right. I pushed the change. I still have some matchers Unit tests that are failing :confused:

Because of the i18n issues? Yeah they all need to be `JsonConvert.Serialize(testValue)` instead of just a string interpolation, then they'll format correctly

yeah some mistake we had before, I'll look at it at the very end :wink: I'd like to spend some time on the provider side.

Yeah no probs. We should fix that in the release branch instead of this one anyway :thumbsup:

> I'm still not convinced about the Consumer verification of the message. It's done by the MessageReify method on the RUST (Verify<T> of the NativeMessageBuilder) that returns an object with a property Contents that has the message without the matchers. There is a double deserialization... therefore I'm not sold on it just yet ^^

Could you please elaborate on this?

Reify doesn't validate anything, just so we're clear (I think you know this)

If you can easily strip the matchers in .NET you don't need to call reify

But in some ways it's safer, because the object that is returned is what Pact thinks it saw, so there are less chances of error

Yeah using reify is better because stripping matchers is non-trivial (it's all recursive and stuff :joy:). I think Yann's problem is that the reified message appears to be double serialised/escaped so it's difficult to work with

Hmm need to remember the decision there. I needed to be escaped I think because the payload isn't necessarily JSON

Eg. If it's binary it'll be base64 encoded But we can change that if easier

Let me know

Hey @matt.fellows I was referring to the implementation on the branch itself, not the approach :slightly_smiling_face:

I do a reify, get the object, use the content without the matchers and use it to check the consumer handler. The only thing I'm not sure of is the way I deserialize it :wink: mainly implementation details.

Ah cool, carry on then :rolling_on_the_floor_laughing:

Hi guys, a little update on the provider implementation of messaging support. I'm making good progress for the verification process. (was able to verify a PACT message contract with the CLI verifier) I'm adding a middleware in the library that could be easily added to an API that wishes to use the message interaction model as part of their verification pipeline. It follows the approach of having a proxy to check the request going in here (https://github.com/pact-foundation/pact-message-demo) The user would just have to add some kind of message scenario invoker to produce the message based on a named interaction. Some roadblocks I ran into and not sure on how to deal with just yet: ? How to deal with the non existant log on the verification side (this one is painful, I see the rust is only calling the verifier CLI but having zero log for the verification process hurts. Something we have to work on in the 4.0.0 feature branch) ? Adding a net core message middleware will work with certain version of the framework and therefore will be limited (likely net standard 2.0 or greater) Let me know if you have any feedback. Thank you

There are logs, are you not enabling them? Or is this that xunit thing that swallows them?

We have a new log setting to log to different sinks but that may not yet be released

That could mean to could buffer the logs and print, or write to file etx

you are right, there is an init method for the FFI but we don't use it. We just set the log level in the .net lib. I'll look into how to pass the right configuration.

EDIT: actually we do..... mea culpa :smile: I'll focus on finishing the middleware and then I'll look into the log problem haha

haha

I?m going to look at releasing the latest rust libs in the next few days, and get Pact go using them

Hi all - sorry I've been away for a while. I was on vacation and then you know what it's like when you get back :smile: I've just fixed and merged my chore MR about verifying SHA sums of downloaded native libs.

From a bit of local testing, I think we need to change the consumer verification API slightly, which actually brings it more in line with how JS/Go work I think. The current API is like: ```using (IPactContext context = this.pact.Build()) { var client = new EventsApiClient(context.MockServerUri); await client.Invoking(c => c.GetAllEvents()).Should().ThrowAsync<Exception>(); }``` but the problem that I've found is that if the test fails, the `Dispose` method throws on the pact context, and then the inner exception gets swallowed. I think the new API needs to be more like JS/Go with a lambda: ```this.pact.Verify(ctx => { var client = new MyClient(ctx.MockServerUri); await client.FooAsync(); }``` That way if the client call fails then we can surface that exception instead of swallowing it during the dispose What do people think? It's not a difficult change, just something I can do quickly once we're agreed

I wish I didn?t have to do that in JS/Go, because it makes the code a bit more verbose/less readable. But it does have a number of upsides

The other thing I did recently, was to write Pact tests for our terraform provider. Doing so, I made a bunch of little updates to the error output. Each language is going to be different, but I managed to be able to get the line number of the test that was failing and provide a nice little diff ```--- ? Running Pact tests go test -tags=consumer -count=1 -v http://github.com/pactflow/terraform/client/... === RUN TestClientPact --- PASS: TestClientPact (0.00s) === RUN TestTerraformClientPact === RUN TestTerraformClientPact/Pacticipant === RUN TestTerraformClientPact/Pacticipant/CreatePacticipant === RUN TestTerraformClientPact/Pacticipant/ReadPacticipant === RUN TestTerraformClientPact/Pacticipant/UpdatePacticipant === RUN TestTerraformClientPact/Pacticipant/DeletePacticipant === RUN TestTerraformClientPact/Team === RUN TestTerraformClientPact/Team/ReadTeam === RUN TestTerraformClientPact/Team/CreateTeam === RUN TestTerraformClientPact/Team/UpdateTeam === RUN TestTerraformClientPact/Team/DeleteTeam === RUN TestTerraformClientPact/Team/UpdateTeamAssignments === RUN TestTerraformClientPact/Secret === RUN TestTerraformClientPact/Secret/CreateSecret === RUN TestTerraformClientPact/Secret/UpdateSecret === RUN TestTerraformClientPact/Secret/DeleteSecret === RUN TestTerraformClientPact/Role === RUN TestTerraformClientPact/Role/CreateRole === RUN TestTerraformClientPact/Role/ReadRole === RUN TestTerraformClientPact/Role/UpdateRole === RUN TestTerraformClientPact/Role/DeleteRole === RUN TestTerraformClientPact/User === RUN TestTerraformClientPact/User/CreateUser === RUN TestTerraformClientPact/User/ReadUser === RUN TestTerraformClientPact/User/UpdateUser === RUN TestTerraformClientPact/User/DeleteUser === RUN TestTerraformClientPact/User/SetUserRoles === RUN TestTerraformClientPact/Token === RUN TestTerraformClientPact/Token/ReadTokens === RUN TestTerraformClientPact/Token/RegenerateToken === RUN TestTerraformClientPact/Webhook === RUN TestTerraformClientPact/Webhook/CreateWebhook === RUN TestTerraformClientPact/Webhook/ReadWebhook === RUN TestTerraformClientPact/Webhook/UpdateWebhook === RUN TestTerraformClientPact/Webhook/DeleteWebhook === RUN TestTerraformClientPact/Webhook/AuthenticationSettings === RUN TestTerraformClientPact/Webhook/AuthenticationSettings/SetTenantAuthenticationSettings === RUN TestTerraformClientPact/Webhook/AuthenticationSettings/ReadTenantAuthenticationSettings client_pact_test.go:932: Pact Verification Failed for: TestTerraformClientPact/Webhook/AuthenticationSettings/ReadTenantAuthenticationSettings Diff: actual: GET /admin/tenant/authentication-settings (Unexpected request was received) expected: GET /dmin/tenant/authentication-settings (Expected request that was not received) client_pact_test.go:942: Error Trace: client_pact_test.go:942 Error: Received unexpected error: system unavailable please see the log for error details Test: TestTerraformClientPact/Webhook/AuthenticationSettings/ReadTenantAuthenticationSettings --- FAIL: TestTerraformClientPact (0.10s) --- PASS: TestTerraformClientPact/Pacticipant (0.02s) --- PASS: TestTerraformClientPact/Pacticipant/CreatePacticipant (0.01s) --- PASS: TestTerraformClientPact/Pacticipant/ReadPacticipant (0.00s) --- PASS: TestTerraformClientPact/Pacticipant/UpdatePacticipant (0.00s) --- PASS: TestTerraformClientPact/Pacticipant/DeletePacticipant (0.00s) --- PASS: TestTerraformClientPact/Team (0.02s) --- PASS: TestTerraformClientPact/Team/ReadTeam (0.00s) --- PASS: TestTerraformClientPact/Team/CreateTeam (0.00s) --- PASS: TestTerraformClientPact/Team/UpdateTeam (0.00s) --- PASS: TestTerraformClientPact/Team/DeleteTeam (0.00s) --- PASS: TestTerraformClientPact/Team/UpdateTeamAssignments (0.00s) --- PASS: TestTerraformClientPact/Secret (0.01s) --- PASS: TestTerraformClientPact/Secret/CreateSecret (0.00s) --- PASS: TestTerraformClientPact/Secret/UpdateSecret (0.00s) --- PASS: TestTerraformClientPact/Secret/DeleteSecret (0.00s) --- PASS: TestTerraformClientPact/Role (0.01s) --- PASS: TestTerraformClientPact/Role/CreateRole (0.00s) --- PASS: TestTerraformClientPact/Role/ReadRole (0.00s) --- PASS: TestTerraformClientPact/Role/UpdateRole (0.00s) --- PASS: TestTerraformClientPact/Role/DeleteRole (0.00s) --- PASS: TestTerraformClientPact/User (0.02s) --- PASS: TestTerraformClientPact/User/CreateUser (0.00s) --- PASS: TestTerraformClientPact/User/ReadUser (0.00s) --- PASS: TestTerraformClientPact/User/UpdateUser (0.00s) --- PASS: TestTerraformClientPact/User/DeleteUser (0.00s) --- PASS: TestTerraformClientPact/User/SetUserRoles (0.00s) --- PASS: TestTerraformClientPact/Token (0.01s) --- PASS: TestTerraformClientPact/Token/ReadTokens (0.00s) --- PASS: TestTerraformClientPact/Token/RegenerateToken (0.00s) --- FAIL: TestTerraformClientPact/Webhook (0.02s) --- PASS: TestTerraformClientPact/Webhook/CreateWebhook (0.00s) --- PASS: TestTerraformClientPact/Webhook/ReadWebhook (0.00s) --- PASS: TestTerraformClientPact/Webhook/UpdateWebhook (0.00s) --- PASS: TestTerraformClientPact/Webhook/DeleteWebhook (0.00s) --- FAIL: TestTerraformClientPact/Webhook/AuthenticationSettings (0.00s) --- PASS: TestTerraformClientPact/Webhook/AuthenticationSettings/SetTenantAuthenticationSettings (0.00s) --- FAIL: TestTerraformClientPact/Webhook/AuthenticationSettings/ReadTenantAuthenticationSettings (0.00s) FAIL FAIL http://github.com/pactflow/terraform/client 0.273s FAIL make: *** [pact] Error 1 ? terraform git:(master) ?```

In my case, having it in a closure made that a bit easier

It's actually a good idea. I was eluded to that when I was referring to hiding the pact.Build() method a while back. It's a much more elegant way to write it as well forcing the client to use the pact instead of a code snippet. Footnote: The messaging will work the same way by the way.

Hi everyone, I pushed my latest changes in the https://github.com/pact-foundation/pact-net/tree/feature/messaging-support branch. Provider verification for messaging is available in the branch. Messaging support works with dynamic messages when you set up your scenario using a scenario builder. See sample app here: https://github.com/pact-foundation/pact-net/tree/feature/messaging-support/samples/EventImporter/Provider.Tests The point is to setup a simulated message that will come from your API rather than pushed in the queue and compare it to the message in the contract interaction. The functional key would be the interaction description. Let me know what do you think about this implementation.

If you check the MessageMiddleware, you can see where the message is actually invoke and set in the http response: https://github.com/pact-foundation/pact-net/blob/feature/messaging-support/src/PactNet.Native/Messaging/MessageMiddleware.cs

All the unit tests have been fixed and the CI is working. I just need to finalize the unit tests and it will be all good :sweat_smile:

So examples of the new API with a `Verify`/`VerifyAsync` method for consumer interaction verification, as mentioned: ```this.pact .UponReceiving("a request to retrieve all events") .Given("there are events with ids '45D80D13-D5A2-48D7-8353-CBB4C0EAABF5', '83F9262F-28F1-4703-AB1A-8CFD9E8249C9' and '3E83A96B-2A0C-49B1-9959-26DF23F83AEB'") .WithRequest(HttpMethod.Get, "/events") .WithHeader("Accept", "application/json") .WithHeader("Authorization", $"Bearer {Token}") .WillRespond() .WithStatus(HttpStatusCode.OK) .WithHeader("Content-Type", "application/json; charset=utf-8") .WithJsonBody(expected); // async version await this.pact.VerifyAsync(async ctx => { var client = new EventsApiClient(ctx.MockServerUri, Token); IEnumerable<Event> events = await client.GetAllEvents(); events.Should().BeEquivalentTo(expected); }); // sync version this.pact.Verify(ctx => { var client = new EventsApiClient(ctx.MockServerUri, Token); IEnumerable<Event> events = client.GetAllEvents(); events.Should().BeEquivalentTo(expected); });``` That's needed because the previous API with an `IDisposable` meant that if the interaction itself threw an exception, that exception would be swallowed silently because the exception from the `Dispose` would be thrown instead.

The `ctx` arg to the lambda is of type `IConsumerCOntext` and currently only contains the mock server URI so that you can use it when constructing your client. The reason I did that instead of just passing the URI itself is so that we wouldn't need a breaking change in future if we ever wanted to pass additional arguments.

Here's the MR to fix the problem: https://github.com/pact-foundation/pact-net/pull/302

Hey @pact544 This is perfectly understandable from the consumer side.

I finished your review. Just a few comments :slightly_smiling_face:

Cool, I'll check it out, thanks!

I forgot about the Invoking (FluentAssertions). It's SOOO handy

Nice work, @pact544! Looks like a good quality-of-life improvement for users

Friends, I?ve made a start (locally) on a ?pact features? document, to record the things that are in each implementation. It?s quite small so far: ```$ cat pact-features.md ## Messages Provider Verification Provider verification with metadata Consumer Tests Consumer tests with matchers Consumer tests with metadata```

but, while going through the V3 upgrade it seems like a good time to take note of what is in a Pact implementation

We don?t really have anything that tracks the different status of features in each framework

See also https://pact-foundation.slack.com/archives/C021XTMRKM1/p1622616027091900?thread_ts=1622459516.072500&cid=C021XTMRKM1

and https://pact-foundation.slack.com/archives/C021XTMRKM1/p1623483029005100

I've merged the changes to the consumer tests API, thanks for reviews @yann.courtel and @tjones :thumbsup:

Greg - Tim is also based in Australia. Perhaps we can organise a call in the next few weeks to chat about this?

I just spoke to Tim, and we both think it would be a great addition to have documented. Even if we don?t yet implement (via tests), having the behaviour documented would be a really great start

Thank you! I'll have the change onto my dev branch and hopefully I will have time today to do a PR also.

Hi everyone, I created a draft pull request for the messaging support : https://github.com/pact-foundation/pact-net/pull/309 Can you have a look and see if anything jumps out? Let me know also if something is not clear. A couple of things might be left to do is to work on a middleware that is compatible with .net core app 1.0 and .net framework 4.6. Right now the provider middleware for messaging is only compatible with netstandard2.0+ Another will be to run the tests with a netcoreapp1.0 framework. I haven't had time to work on that. Thank you.

Hi everyone ! Question regarding a method of the FFI @matt.fellows and @uglyog What is this method actually for ? It seems to allow the writing of metadata from the message pact handle. We do have then the normal message interaction metadata and the pact metadata where the pact specs and rust version are, is that correct ?

yeah. This is for adding extra data into the pact file

My initial thoughts were to add the details of the client library

e.g. perhaps `pactNet.version` would be good to have in there?

The metadata can be displayed into the pact broker, to help with bug diagnosis etc.

We actually initiate a PactV3 or in the Future PactV4 that will set the specifications automatically (with the WithSpecifications). So I think that would be redundant. I'll try adding another version just to see if it works though :)

It's not the spec version, it's the version of Pact .NET we'd put in there

The spec version is automatically added there by rust

We discussed also using it for feature flags(potentially language specific) and similar things

Here is what Pact-JVM puts in there: ```"metadata": { "pact-jvm": { "version": "4.2.8" }, "pactSpecification": { "version": "3.0.0" } }``` and Pact-JS V3 ```"metadata": { "pactJs": { "version": "10.0.0-beta.33" }, "pactRust": { "version": "0.8.11" }, "pactSpecification": { "version": "3.0.0" } }```

We can then show this info in UI (this is from Pactflow)

I've done a rather large (sorry :smile:) review of the message pact branch :thumbsup: Hopefully it's not too harsh! I think we need to change the API somewhat though in order to maintain consistency with the request/response pacts, and to use the type-state pattern so the user falls into the pit of success instead of allowing them to potentially make mistakes and us validate their actions afterwards. I think we also need to revert any 'cosmetic' changes to make the diff easier to read (like removing `this.` or adding spaces in `using` declarations at the top). I very nearly missed some new code in the middle of a bunch of those cosmetic changes. We should generally agree a convention and stick with it so it's easier to navigate the codebase as a whole anyway I think. And obviously I think my preferences should be the default because I went first :stuck_out_tongue_closed_eyes::joy:

adam, you're very cheeky. I suspect that Matt prefers we adopt the C# recommendations, which means the project never adopted some practices early on and now we have some cosmetic chagnes - but your right, they have cleverly masked other changes

Thank you very much for the large review! I agree with the leading the user to the path of success typing there request and managing invariants but how would you achieve that? I agree with everything except the "And obviously I think my preferences should be the default because I went first" ^^ These cosmetic changes are resharper default considerations for most and I think we should stick to that and avoid any unnecessary code. (except the spacing in the using, I can revert that) What I can agree with is to do it in another PR so we don't crowd this one. Therefore, we can talk about it later and decide and how we configure our IDE. I'm going through all the changes so some answers will come through the PR :slightly_smiling_face: thanks again

Thanks @uglyog in .net, we actually append the rust version as well which is very useful.

> I agree with everything except the ?And obviously I think my preferences should be the default because I went first? ^^ :laughing:

I like that Greg suggested I had opinions here (I do, but not the ones you?re expecting probably)

My suggestion is to get the rules identified now, because once it?s merge into mainline, cosmetic refactors are a pain in the butt for git-blame etc. - e.g. now the last person who changed it didn?t really change it, they just made it pretty

> Thank you very much for the large review! I agree with the leading the user to the path of success typing there request and managing invariants but how would you achieve that? If you separate out the "things you can do to an interaction" into a separate interface, and the "start a new interaction" method return the first interface, then you are forced to start a new interaction before you can configure it. That means you don't need to validate "trying to configure an interaction before you've actually started it"

So for the request/response style it's `IPactBuilder.UponReceiving` which returns `IRequestBuilder`, which has all the `WithPath`, `WithQuery` etc. That means you never need to validate that `WithQuery` isn't called before `UponReceiving`, because it's literally impossible to do that

So if you did like `IPactBuilder.ExpectsToReceive` which returns `IMessageBuilder` (or whatever it's called) then you can't get it wrong

Okay, so sticking with different level builders to avoid any invariant. I can prob do like that. The problem will come when we want to call the build method after the verify since it's another builder. I could always reference the parent builder in the sub-builder and see how it looks.

@greg595au @matt.fellows Agree with the conventions. The questions is which conventions? :smile: There are may out there => we could use the microsoft ones https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines Or we could adapt certain conventions to match our IDE... What @pact544 was suggesting mainly (I think so ^^) was not to mix it with the messaging, that way, we can apply the new conventions in the feature/4.0.0 branch later on. We should start a different thread to talk about it.

Yann - i think ur link points to this one: https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions

@greg595au that is the second sublink to the link I copied :slightly_smiling_face: since it's not just coding conventions but also namespace and so on.

Hey everyone :slightly_smiling_face: I looked at all the remarks you've sent @pact544. Some work to do which I will be doing mostly tomorrow. Some points I'm not 100% sure of yet but for most I can fix. Thank you again for the review.

:taco: :taco: for @yann.courtel

:taco: for @pact544

This is great

I have the code open now, and don?t know where to begin - so much stuff!

@pact544 saw this, and agree. It? seems strange to me that that?s not a thing.

Current state of that crate: https://github.com/env-logger-rs/env_logger/issues/113

See also https://github.com/pact-foundation/pact-reference/pull/119. There is a new method to log into core, and another to initialise with the log level directly (rather than needing an env var to set it).

But it doesn?t allow you to change it after init

Yeah we'd need a static property on PactNet that you can set, and you'd have to set it before you did any work with the library at all (and probably throw an exception if someone does try to do that). We should raise it as a ticket to use the new core logging method :+1: Shouldn't be difficult once it's in an official pact-rs release

Always start by the tests :wink: the integration one, on the sample projects will give you a good idea.

Hi everyone, sorry for the delay on the messaging, I had one of those weeks... I'll be back next Thursday to try to push the branch for end of next week! Enjoy your weekend.

cc: @elliottmurray

has joined #pact-net-development

:wave: hey folks, just wanted to check-in to see how things have been traveling?

There?s been lots of activity in the code, which can be overwhelming for a http://non-.NET person - but do reach out if there are spots that we can help guide etc.

Related to this, we?ll probably have the next Pactflow POST go out in the next week or two. It?s likely we?ll include Pact Go?s support for v3 has moved to beta to help drive some adoption.

I?m not sure if it makes sense to mention .NET just yet, I don?t believe it?s currently distributed to Nuget right? If you need any help with that, reach out as I do currently have access. But I know DiUS (my employer) is doing some work with a .NET client at the moment, and I?d love to get this in their hands to take it for a spin.

I was kinda waiting until the new combined FFI came out and then perhaps update the 4.0 branch to start using that instead. We're still a decent way from beta I think just because the logging support is behind where it used to be with the Ruby integration. In particular the verifier logging is lagging some way behind I think. Other than that it's all the documentation and stuff that goes round it that all needs updating, and should be good to go.

The new FFI is out, ICYMI

I?ll probably take a look at it today for Pact Go, just to wrap my head around it

@erik.moller the v4 branch is currently here: https://github.com/pact-foundation/pact-net/tree/feature/4.0.0

Hey @pact544. Back from vacation :slightly_smiling_face: I saw your changes for the logging. I will check that out on the messaging branch right away.

I looked at your PR and it looks okay. Can we merge it and see if it works in the 4.0.0 branch? I'd like to verify it to the messaging branch. Thanks

Yeah we can merge if it works :+1: I've also been away for quite a long time so not sure if there's an updated core library with unified logging yet.

I'm making a start on moving the FFI over to the new combined FFI now. Wish me luck!

OK it's quite a bit different. This isn't going to be a quick one!

Argh, the file name structure has changed again (so Linux and OSX are called `libpact` whereas Windows is just called `pact` ). I think that breaks the download script :disappointed:

> OK it?s quite a bit different. This isn?t going to be a quick one! I think the main difference is that they have prefixes (that discussion was ? _somewhere_)

But the name difference seems wrong

We can easily change that

Yeah sorry, I immediately jumped into the new iterators bit for verification failures and thought the old way had gone, but since found it.

The name difference for the OSX library actually doesn't seem to matter - the tests pass on CI anyway

I approved it, go for merge.

@pact544 @yann.courtel FYI @edanielsen has just updated https://github.com/DiUS/pact-workshop-dotnet-core-v2 based on your branch! Very cool (we have pushed a build to a public artifactory so it can work). I?ve yet to look at it, but just know that people are champing at the bit. Also as you might have seen, the feedback for the new API has been :mwah:

Thanks a lot. That's a very nice repo here!

(for reference, it?s based off the previous workshop)

Oh nice :+1: yeah once we've got nice logging for both consumer and provider sides I think it's worth releasing a beta. Messaging support can be added soon after that I think, but nice to get the core stuff out.

I had a similar repository for our lib encapsulating pact-net. The good thing is to put different levels including as @pact544 pointed it out, an exercice with different interaction model such as messaging.

It can also serve as an integrated environment / solution to troubleshoot any issue we might have (related to how many tests on many classes we have)

exactly!

good idea

Hi everyone, A PR to merge the consumer part of the messaging : https://github.com/pact-foundation/pact-net/pull/315 A lot of structural changes made it difficult to rebase so I split the consumer and provider part to be easier to review. There should be minimal changes since it has been reviewed in the other PR here: https://github.com/pact-foundation/pact-net/pull/309 Thank you for your feedback.

We have a 100% Unit Tests cover on the new code. After the messaging, I will make a pass on the Unit and Integration Tests to achieve 100% overall coverage. Thanks

awesome work team

Hi everyone, hope all is well. I think it may be time to have 'the talk'. Yes, I'm talking about *coding and naming conventions* going forward :slightly_smiling_face: For this, I'm thinking of making *a poll* with the different approach we could take. I have many sources (online and first hand) that don't necessarily agree on which conventions are the best... Microsoft : https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions DoFactory : https://www.dofactory.com/csharp-coding-standards (to cite just a few) I'll post it as soon as I have it. Thanks

I addressed all of your comments @pact544 For the sample app, we will find later an example with many messages. Maybe on a later PR. With one message for each message PACT, the metadata do appear! Might be a bug. For the verifying the metadata on the consumer side comment, I don't know how you would do that...

Can't verify metadata on the consumer side, at least the others don't do it that I'm aware of

and actually it doesn't make sense when you think about it from a pact perspective. They are all going to be different from the type of messaging queue you are using. But one thing is for sure is that if your object has a different structure, your consumer should rightfully break. In other words, you can switch the type of queue but if you have the same structure of the object, the pact should work.

has joined #pact-net-development

Hi guys, I might not be a major contributor going forward (though you never know), but I happen to be helping a client introducing pact at the moment (I work for DiUS, like some of the other folks here), and they happen to use .Net core mostly so when I find a missing feature I might just look at implementing it :smile: I'll see if I can pitch in with some documentation help as well since I had to do some of that while putting together a dotnet workshop modelled on the JS one. Awesome work on the 4.0.0 branch by the way, if it wasn't for that I don't think I would have gotten anywhere with http://Pact.Net

I should probably also say that I'm not a .Net developer (far from it), in fact I've never used it before, but I found it quite intuitive coming from a Java background. Still, if you see me doing something weird it's probably because I don't know better