has joined #pact-dart

has joined #pact-dart

Lewis - I?d suggest starting with creating a feature request here: https://pact.canny.io/

this way we can get voting etc. happening

But we can use this channel to discuss any support you might need if you wanted to start it. If not, the channel will live until such time that somebody else wants to :slightly_smiling_face:

Awesome - I will take a look at what's involved as I have only been a _*consumer*_ (no pun intended) of the PACT framework, but would love to contribute

has joined #pact-dart

has joined #pact-dart

Hi there! My name is HeyTaco!, and you can use me to give people tacos to show your appreciation. My tacos will spread joy through Slack!

Very tempted to use custom interceptors in Dio to generate a pact contract

There are (current) problems with generating contracts this way, but I see this as almost the default path in the long run.

see https://pactflow.io/blog/a-disastrous-tale-of-ui-testing-with-pact/ for a bit of background on the problem

also https://pactflow.io/blog/cypress-pact-front-end-testing-with-confidence/

But as I said, more interceptor based approaches will be happening soon (including in a Cypress plugin)

I will take a look

Maybe it's best to just use https://pub.dev/packages/http_interceptor#building-your-own-interceptor

If I wanted to use the pact broker instead where do I start? Need to try to workout how I can get the broker running from dart

The pact broker is a shared piece of CI infrastructure to publish the contract to

So you would normally run it in e.g. docker

There is an example docker compose link in the broker repo

I think

Okay so I would like to try and do this with the following plan of attack... 1) Create a flutter driver extension (as seen here) to drive the pact setup in tests 2) In the above driver, run a .sh script to install the pact CLI and setup the mock service

I have never done anything like this before and if this is flawed, let me know. I have a feeling that step 2 should probably use docker instead of a script but could do with a bit of advice on this

Very excited as I have written a pact consumer that validates a PactInteraction against mock web server in dart that captures http requests

Got it to successfully pass a test just need it write the actual contract

And a bit of refactoring is needed

So this is very PoC, but I am in the progress of creating a PACT consumer for Dart. Which I am hoping will be popular among flutter developers. It's pretty rough and ready but I have achieved my first goal of being able to have a server catch the interactions sent by the Dart http client. https://github.com/lemusthelroy/dart-pact-testing

has joined #pact-dart

has joined #pact-dart

Awesome!

I?ll take a look at this on my next OSS day

I'm currently working on a couple of flutter sample apps, so this'd be very helpful to try

(and I personally only need http intercept, no UI or anything)

has joined #pact-dart

Awesome, I think my next steps are to turn this into a dart package and then try to implement matchers in dart

has joined #pact-dart

And then I found this...https://github.com/thomaslevans-wf/pact_consumer_dart

Haha

Well that uses the legacy Ruby interface so if you stick with the new Rust one you'll be :ok_hand::ok_hand:

I think this is where I get a bit lost...is there anything wrong with writing a custom implementation that just generates contracts in the correct format as per the specification?

well, not directly

Generating a contract itself is not necessarily the hard bit, although there are subtleties in the specification that could introduce compatibility issues over time

It?s more that having a central engine almost guarantees that compliance and consistency

There are other benefits in that engine too - new features can generally be pushed out faster across the ecosystem this way (and we?ve seen the benefits of doing this over the past year as we?ve added a number of features with the pact broker)

again, to be fair, most of that capability is in provider tests

My understanding is that dart is very much a general purpose language, but it?s popularised by Flutter

@marko.justinek may have a perspective to share relating to Swift, which I think is in a similar boat

has joined #pact-dart

Ask away if you have anything specific to ask. Feel free to peek into surpher/PactSwift as well. surpher/PactSwift is using pact-reference/rust/pact_mock_server_ffi for the in-process pact_mock_server which Matt mentioned and takes care of writing the pact file for us and we can run our pact tests against it instead of running external mock server (eg pact-ruby-standalone or something like that). It makes it compliant and consistent and we can share the bugs across platforms too :tada: (well, it just means they get squashed sooner) PactSwift does generate the Pact objects/contract and passes it into pact_mock_server_ffi as it PactSwift was designed and developed just before pact_mock_server exposed the endpoints to build the contract by dripping it provider states and consumer expectations. There are obvious benefits of using rust/pact_mock_server, although I?ve hit major issues with multiple platforms/architectures swift can run on (and now with Silicon I?m facing even more challenges). We can?t use dynamic libs on iOS which is a bummer (though I need to confirm with XCFramework and how that would work). Not having dynamic libs is a big pita building (clean build times are ridiculous), static libs are enormous, GitHub doesn?t offer free Git-LFS bandwidth and storage so we can bundle the pact_mock_server in the framework easily/nicely? I?ve uncovered a Swift bug with generics too while writing the `PactBuilder.swift` ? So? there are challenges ahead. So keep an eye out on that.

if you want to play with the rust implementation here?s my gist to help me remember what I need to do for macOS and iOS when I get back to it after a while

Ah yes, the joys of linking!

So I get the push for consistency as I can imagine having several different frameworks verifying pact in different ways will cause inconsistencies. From a dev ex point of view it does mean that using pact in dart it isn't as simple as installing a dart-pact package and following the docs...you also have to install the pact-standalone

apologies if I use the wrong terminology at any stage

all good. All questions are welcome!

what do you mean by installing the pact-standalone? the ruby like standalone mock server?

Yeah I'm a bit confused as when I look at the javascript docs for example

there?s also the c(something) CLI that does the thing for you and is based on the rust implementation, right @matt.fellows ?

there is no need for a standalone mock server

you just install the package and crack on

unless I am missing something

similar with PactSwift now (apart from a bit of post import setup required)

it uses the rust/pact_mock_server as a dependency

We are in a transition state for Pact JS. It?s one of the most used libs, so that is taking a bit longer

We have a beta branch that doesn?t use the Ruby standalone thing

c based so it runs in-process? eg, no need to start your server externally and create an API client in your framework to call it

ah okay

> From a dev ex point of view it does mean that using pact in dart it isn?t as simple as installing a dart-pact package and following the docs...you also have to install the pact-standalone Ideally, any dependencies like this are transparent to the users of course. If that can?t be achieved, it?s worth weighing up the pros / cons.

so coming from a very basic background in dart, I am thinking I need to find a way of spinning up the rust mock server

Ummm? it?s late here, my brain might not be braining but can?t think of it

maybe my brain is not connecting things properly either :joy:

so I guess the flow is, ? write the test in dart ? execute test ? test sends call via http to rust mock server ? dart should then handle response from rust mock server in test

Yep. You actually have three choices (I think) ? Download the mock server https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_mock_server_cli (ideally, your framework / package manages all of this) and communicate to it remotely ? Use the FFI (c) https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_mock_server_ffi ? write your own

cool, so currently I have gone down third route which I think would be a mistake

I think so

but that's the whole point of doing a PoC

Just remember - the generating the contract bit is the easy bit (it?s fairly trivial to create a DSL that can be converted into a JSON file). The hard bit is to interpret the specification in a consistent way, spin up a mock server of your own that listens on a port, does all of the verifications and error reporting etc.

It sounds like a little bit, but it will be a few months of work I?m sure.

Cool, think my next task is to read up on the documentation for the rust mock server

I?m quite fresh with it so feel free to shoot me any questions

Swift related of course :blush:

I also might have picked the wrong time to write PactSwift, macOS BigSur and Apple Silicon broke everything? of course

it?s late now, fixed and moved the example project to GitHub actions so I think I should retire for tonight

@lewis.thorley you?ll get heaps of support here, @matt.fellows is great with sharing and direction and I?m really fresh with Swift/Xcode using https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_mock_server_ffi

I?d first look into how to interact with libraries built from Rust code in your Dart project

also, there are heaps of bash scripts and workflows showing how Rust pact_mock_server is compiled and linked in surpher/PactSwift. It would probably be a pretty good reference

Btw @lewis.thorley, I go on leave (from work) for a month starting Wednesday, so I may be free to help build stuff, if you want a pact buddy :slightly_smiling_face: I'm pretty fresh to Dart & Flutter, but I know many other languages, and I've been using Pact for a lot of years by now :sweat_smile:

has joined #pact-dart

@goncalosamuel hello!

has joined #pact-dart

Thanks for your contributions so far Goncalo. It?s exciting to see so much interest in Dart. I know @lewis.thorley was also doing some work in this space

It would be great to be able to combine your efforts so that we don?t end up with 2 fragmented libraries

We aim to have 2 core maintainers for every language, to provide some redundancy, diversity in thought, ability to sense check work etc.

Also, we know, not everyone will have energy that remains forever, so having another person means the project will carry forward whilst another person can step in

If you like, we can help broker a conversation. But as a start, maybe if you could share what your plans are moving forward?

As discussed on the open issue, we?d like to move to a shared engine - see https://docs.pact.io/implementation_guides/other_languages

The main reasons for a ?shared core? are: 1. Reduces the types of cross language bugs that have caused many issues over the years 2. It also reduces the time to market for a certain class of features 3. It means the library maintainer can focus more on developer experience and idiosyncrasies for the user, rather than the heavy lifting of the core itself 4. See also https://github.com/pact-foundation/pact-specification/issues/83 for some background on the shared core, and the related plugin ecosystem that we want to use to drive improved time-to-market

Hi @matt.fellows! Thanks for adding me. I'll look into more detail to your message later on the day :wink:

has joined #pact-dart

Hi all, I'm Nuno and I'm doing the maintenance of the pact library with Gonçalo. I've looked into the plugins proposal and I'm still puzzled about how it will solve cross-platform support: . Even if we have a plugin ecosystem, we still need to have some kind of language specific library to interact with the plugin, right? Sure things may be autogenerated if we apply communication protocols like gRPC but then all the DSL goodies would fade. . Another question I have is, since the plugins can be built in any language, to use the plugin we would need to launch the specific ecosystem for it right? JDK for Java, .Net for C#, Dartvm for Dart, etc. Sorry for the long post :)

:wave:

Great to hear you?re keen!

As for plugins, it doesn?t aim to solve that problem - it aims to create a generalised solution to extend functionality quickly. If authors choose to create a plugin in JS that?s not compatible across OS or languages, that is not necessarily problem in my opinion, because it will be useful for some community. Of course, where possible cross-platform plugins should be created - so languages like Golang, Rust and other compiled languages that can easily produce cross-platform artifacts might be preferable, and from a Pact framework perspective we?ll certainly be aiming to create plugins that are robust in this fashion. But if you work in a large enterprise and have a specific need to extend Pact for your specific case, you shouldn?t be bound by complicated constraints to create cross platform/OS artifacts, for example. > Even if we have a plugin ecosystem, we still need to have some kind of language specific library to interact with the plugin, right? Sure things may be autogenerated if we apply communication protocols like gRPC but then all the DSL goodies would fade. Not necessarily. The best plugins may do that - that would be up to each language to add the thin DSL layer over any plugins (e.g. a type system, builder pattern etc.). But it should be thin, and it should be a separate extension. It also should be able to be used without it (language for these things is still something we?ll need to work through, but you could consider a no-DSL interface the ?raw? one). Otherwise, we end up with ?each language has to create the DSL from scratch? problem, which is why we?re doing this in the first place. > . Another question I have is, since the plugins can be built in any language, to use the plugin we would need to launch the specific ecosystem for it right? JDK for Java, .Net for C#, Dartvm for Dart, etc. The plugins should be executable in one way or another, independent of the language that is using it (e.g. JS). Ron has ideas on how to make this more reliable, but in the worst instance, each plugin may have its own process for configuring and starting it. Again, see the goals of the plugins to see how we might prioritise that sort of thing

does this make sense?

It's starting to make more sense. You're only trying to address feature parity with that "shared core", and the plugin system itself is just an extensibility mechanism for the core. Is that it? I think it is a solid idea to boost time to market, mainly for features like body/headers matching. Nevertheless, I think language specific support is crucial, which I'm sure you agree.

I'm open to support the plugin idea, but I'm not sure what this means in a short time span.

I know that there is another pact consumer for dart that uses the HTTP mechanism, but the point of making this one was to be as self sufficient as possible with very good language/typing support.

Is your idea to converge both packages into a single "official" one?

I think that?s what I was thinking

But if I?m honest

I didn?t know where to start when using the pact library in dart

Do you mean the lack of instructions on how to use the library or something else?

> Is your idea to converge both packages into a single ?official? one? That would be ideal. More divergence == more confusion == bad experiences for all involved (more support questions, more frustrated users, more frustrated maintainers)

we strongly suggest use of the FFI bindings / shared core. There is a massive source of bugs that is removed by doing this

Have a look at #pact-scala-itv - they are actively pursuing removing their native work, in favour of building on top of the JVM. The reason is simple - it?s hard work keeping up with all of the changes. Also take a look at the pactman library (an alternative for Python). Instead of putting energy into pact-python, the author created a new one from scratch. It doesn?t implement all of the features, but implemets bits of up to v3. Now they?ve moved companies and didn?t bother to build a community of maintainers around it, and now it?s essentially dead.

> I know that there is another pact consumer for dart that uses the HTTP mechanism, but the point of making this one was to be as self sufficient as possible with very good language/typing support. I think this is not incompatible with a shared core.

> You?re only trying to address feature parity with that ?shared core?, and the plugin system itself is just an extensibility mechanism for the core. Is that it? pretty much

> Nevertheless, I think language specific support is crucial, which I?m sure you agree. Of course! It?s definitely a tradeoff. Unless I?m missing something, you can definitely still have your language specific wrapper over it to make it idiomatic and developer friendly

> I?m open to support the plugin idea, but I?m not sure what this means in a short time span. Nothing yet - it doesn?t exist :laughing:

I know that dart has https://dart.dev/guides/libraries/c-interop support, but haven't explored it yet and don't know it's limitations. I can check this out. Do you know how other languages address the binary compatibility problem? If I understood correctly, the shared core is built in Rust, so it needs compatible binaries with the operating system it is running on. From the https://github.com/pact-foundation/pact-reference/blob/master/README.md repo I see they build a local version to use on the FFI examples.

Yep, each os/arch will need a separate lib installed

You can choose to bundle it in the package if that's supported (ideal DX) or have the user install (not ideal obviously)

Do you know how large are the binaries? Bundeling may not be optimal as well.

About 8mb each I think. Check out the release page of that repo

Hum... The `so` files are about ~4mb each, but that is assuming I don't need the statically linked libraries which are ~16mb.

I'll explore this further and give further feedback later

I've made some progress integrating the FFI library in Dart but now I'm stuck I manage to initialize the server up to the point where interactions can be done, but when I try to do them they fail with 500 status. I don't know how to access the logs emitted by the library. Rust is not my thing so help would be appreciated :)

Ooo that?s great progress

Normally it?s called pact.log? Unless that some custom name that I?ve got used to that isn?t the default

If you need any help once you?ve found the log shout up

Have a very close look at what you?re passing to it. I?ve had a lot of 500's as well for ridiculous mistakes. As in having two interactions with same state description (?cause I was too excited and copy pasted interactions and only changed the body), invalid meta or matchers structure,?

you need to call `init()` first

there are a few log functiosn, but the simplest to begin with is to export `LOG_LEVEL=trace` when you run the thing, and it will spit everything out

I?ve created a Swift Package just to wrap the FFI here. This interface is really all I needed (for now): https://github.com/surpher/PactSwiftMockServer/blob/main/Sources/MockServer.swift

Here as the Golang version: ? Mockserver: https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mockserver/mock_server.go ? Example use of the native interface: https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mockserver/mock_server_test.go

I?d suggest starting with something that can do this: https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mockserver/mock_server_test.go#L125-L162

Thanks for your input. It led me to the solution.

I was basically doing everything right, but the server gives 500 whenever he can't match a request and also when the request isn't made.

FYI the log wasn't working because I hadn't the environment variable set. I assumed I needed to pass the value for the actual log level on init, but I pass the variable name.

Yeah that was a bit confusing for me first time too

We recently added some new log methods we need to document

The mock_server_mismatches method should tell you why it failed tho. You should always call this and print out any failures

I wasn't because I had a bug in the boolean conversions from Rust. Once I got the log working, it was a 30 second fix

Question: Shouldn't I be able to set the provider state on the mock server to test specific interactions?

Like a list with and without records

can you please elaborate?

I think the answer is yes, but I?d like clarification

Sure. Lets say I have an endpoint called `/pets`. I'd like to have one interaction that returns a list with content and another that doesn't. From what I read about pact this is a use case addressed by the provider states. On the consumer side, I'd like to call the same endpoint and get two different results, and for that I was wondering how I'd set the provider state in the mock server.

If you?re referring to the FFI interface, that is achieved via the `given` and `given_with_param` method: https://github.com/pact-foundation/pact-go/blob/884ccb0e272649db785ccfffdf6da29d9bd0987e/internal/native/mockserver/mock_server.go#L485-L510

we would say something like ?given that there are pets? and ?given there are no pets?

But this is to build the pact by adding interactions (acording Rust docs). It will fail if the server is started.

I want to set the server to specific state

A running server

Does it make sense?

on the provider side?

No sorry it?s not making sense :laughing:

which server do you want to set?

can you point to an example that shows what you want to do?

:laughing:

```{ "provider": { "name": "pet api provider" }, "consumer": { "name": "pet api consumer" }, "interactions": [ { "description": "should reply with no pets", "request": { "method": "GET", "path": "/pets", "headers": { "accept": "application/json" } }, "response": { "status": 200, "headers": { "content-type": "application/json" }, "body": [] }, "providerStates": [ { "name": "given empty pet list", "params": {} } ] }, { "description": "should reply with a pet list", "request": { "method": "GET", "path": "/pets", "headers": { "accept": "application/json" } }, "response": { "status": 200, "headers": { "content-type": "application/json" }, "body": [ { "name": "Mr Whiskers", "type": "Cat" } ] }, "providerStates": [ { "name": "given pet list with entries", "params": {} } ] } ], "metadata": { "pactSpecification": { "version": "3.0.0" }, "pact-dart": { "version": "0.0.3" } } }``` with this pact file, for instance

when I launch a mock server with it, and call `/pets` it will reply with the contents of the first interaction, i.e. the empty list

is there a way to tell the mock server to use the second interaction? like using a specific provider state

in essence, the mock server acts as a provider right? shouldn't we be able to tell it to use a specific state?

I think you're confusing how the mock server works. It's supposed to take in the interaction for the current test, not all of them.

If the current test needs more than one interaction then you can do that, but not conflicting ones

How did you arrive at that pact file? Did you produce it by hand or via the FFI bindings?

> I think you're confusing how the mock server works. Probably. I'm still figuring out how it works :smile: > If the current test needs more than one interaction then you can do that, but not conflicting ones But this is a limitation of the mock server implementation right? The specification seems to allow it. > How did you arrive at that pact file? Did you produce it by hand or via the FFI bindings? Built the JSON by hand then launched a mock server with it using FFI.

I believe my use case is valid. I want to test the consumer when the API has no data and when it does.

yeah you can totally do that

but the lifecycle is out of sync here

you don?t create the pact file first, and then run the tests

each test should go through the full lifecycle of methods as follows: https://github.com/pact-foundation/pact-go/blob/884ccb0e272649db785ccfffdf6da29d9bd0987e/internal/native/mockserver/mock_server_test.go#L125-L162

The pact file is _generated_ from these tests.

(I would not use the mock server interface that accepts a pact file, which I?m assuming you?re doing above. That means you need to know how to serialise all of the pact file formats, which whilst not super complicated, is non-trivial and work you don?t need to do)

each time you add a new test, it writes a new interaction to the pact file

this way, you can test those scenarios you?re talking about - you don?t need the test to somehow know which one to match

But this strategy will produce a pact file per test. I won't be able to achieve the same end result, which is a single pact file with multiple interactions on the same endpoint with different responses.

No it won't, it will merge the pact into a single one

Trust me!

has joined #pact-dart

Hi all, I've got some updates from my side. I've managed to compose a version of the package that leverages some of the features made available by the rust mock server through FFI. You can check it out https://github.com/pak3nuh/dart_pact_consumer/tree/feature/ffi-integration Unfortunately, due to dart limitations, I can't build the pact files with the external library. Only when I upgrade to Dart 2.12 I can leverage some new stuff. On the plus side, it is possible to have the complete cycle on simple pact files: define->test->publish/export.

has joined #pact-dart

Hey everyone, I?m currently working on writing a dart package that uses the Rust `libpact_ffi` library to generate Pact contracts. I hope to extend it in the future once the mock service supports more features to include other modules like the broker. I decided to write this so that there is a null safe library that does not depend on the Ruby mock service. Feedback or contributions are welcome. :raised_hands: https://github.com/matthewshirley/pact_dart

Q: I current have `libpact` hosted in the `dependencies` folder: https://github.com/matthewshirley/pact_dart/tree/main/dependencies Is this approach okay or should I direct users to download `libpact` themselves?

I think it?s good to provide the `libpact` for users? sake. `PactSwift` is exposing it as XCFramework through a Swift Package. I?ve dabbled with asking users to build it from Rust themselves because `.a` files are now close to 300MB for arm64, sim on x86 and on m1. :exploding_head: Luckily XCFramework format was introduced! But it?s a pita to ask your library users to source it themselves. Or maybe as devs stuck in Xcode we?re a bit apprehensive leaving it? Either way. On the other hand, repo will blow up because of these big files? versions. Only for Linux users PactSwift asks to provide the `libpact_ffi.so` themselves.

I?m not sure how dart works, but if there is the concept of a package manager that you can bundle this into, it would save you committing it to the repo itself

but _definitely_ err on the side of pre-packaging the library if you can. It removes a class of problems (like versioning, proxy issues during package install etc.)

You might want to chat with @nuno.pik @lewis.thorley who have done some work here previously. Having multiple libraries floating about is obviously less than ideal!

Good call, I agree. I decided to create another library because `dart_pact_consumer` does not support null safety intentionally, as per https://github.com/pak3nuh/dart_pact_consumer/pull/9. @nuno.pik or @lewis.thorley ? happy to help contribute to `dart_pact_consumer` if we can commit to null safety in the short term.

https://github.com/matthewshirley/pact_dart/releases/tag/0.2.0 `v0.2.0` introduces a DSL for creating Pact matchers. :tada: ```.withRequest('POST', '/alligator', body: { 'alligator': { 'name': PactMatchers.EqualTo('Betsy'), 'isHungry': PactMatchers.SomethingLike(true), 'countOfTeeth': PactMatchers.IntegerLike(80), 'countOfHumansScared': PactMatchers.DecimalLike(12.5), 'favouriteFood': PactMatchers.Includes('Pineapple'), 'status': PactMatchers.Null(), 'email': PactMatchers.Term(r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$', ''), 'friends': PactMatchers.EachLike(['Beth'], min: 1, max: 5) } })``` Next features to work on is combining matchers and generators.

Great job! Can I suggest: ? request method be an enum value rather than a String. It?s safer. ? Includes() to take an array (or variadic param if that exists in Dart) and have a flag to combine as .AND or .OR? You will enable your users to cover a lot more cases. ?countOfHumansScared? :sweat_smile: are you Bender?

Awesome work Matt!

I like the feature support table, that?s really helpful You might find this re-organisation of the Pact Go docs helpful too - keen for feedback. Please also steal as you like https://github.com/pact-foundation/pact-go/tree/2.x.x/

FYI next week we?ll be publishing our August edition of the Pactflow POST (newsletter), and I?d like to include links to all of the work going on upgrading to v3 / rust integration

I?d like to link to this to drive some feedback

does that sound helpful? If so, would you be keen to give me a short summary of the status of the project, and what feedback you?re looking for?

@marko.justinek ditto with Pact swift.

Hi @matt682 Not sure what you mean by short term, can you be more specific? There are other things we might clash but we can discuss in private if you want.

Ah Nuno, it?s super early where you are! :zzz:

I realised in my excitement that I probably shouldn?t include dart in the mailout next week. As a community, I not sure we want to have multiple implementations. At the very least, we need would want to agree why they exist and when one should be used in preference to another, and also have comfort that they will be supported going forward.

We don?t have any real policies on this, but it?s fair to say we usually like to have at least 1 dedicated (but ideally 2 co-) maintainers before we consider it an official package.

Matt, some feedback also. Whilst you can definitely have matchers on the request, 9/10 you shouldn?t actually need matchers on a request (because it?s a unit test, you should be able to control what your code is doing an therefore matchers aren?t usually needed)

I?d suggest any examples you have in the repo reflect real world use, because I _guarantee you_ you?ll get questions like ?how do I do X?, where X is a standard use case. If your examples cover the standard use cases, they?ll be copy/pasted everywhere

and I?d say request matchers are almost an anti-pattern, which means they?ll be copied everywhere :stuck_out_tongue:

The DSL looks fairly friendly to me though, as a non-dart speaking person, but here are some quick thoughts

```pact .newInteraction('request for betsy') .given('a alligator named betsy exists') .uponReceiving('a request for an alligator') .withRequest('GET', '/alligator') .willRespondWith(200, body: body: { 'name': 'Betsy' }});``` I think it would look better like this: ```pact .newInteraction() .given('a alligator named betsy exists') .uponReceiving('a request for an alligator') .withRequest('GET', '/alligator') .willRespondWith(200, body: body: { 'name': 'Betsy' }});``` the duplicate text in `newInteraction` is not necessary, and is a strange artifact of the FFI lib. You can simply pass in an empty string, so I wouldn?t pass that onto the user of the package because it?s not used.

(also, is that a duplicate `body` there?)

> Not sure what you mean by short term, can you be more specific? @nuno.pik To be more specific, supporting SDK 2.12/null-safety as next steps for that repository instead of working on features. > we need would want to agree why they exist and when one should be used in preference to another It may potentially make sense to have two libraries: ? `PactDart` intended for SDK 2.12+ ? `dart_pact_consumer` intended for older SDK versions, as mentioned on a https://github.com/pak3nuh/dart_pact_consumer/pull/9#issuecomment-858556100in the previously linked PR I believe both implementations have feature parity, I?m unsure if `dart_pact_consumer` depends on Ruby to generate JSON files. I would propose new features go into `PactDart` since I have time to dedicate. Open to different approaches.

> request method be an enum value rather than a String. It?s safer. Good call. :thumbsup: > Includes() to take an array (or variadic param if that exists in Dart) and have a flag to combine as .AND or .OR? You will enable your users to cover a lot more cases. Yes!! I like the PactSwift implementation of `IncludesLike`. I?m going to start working on this tonight. > You might find this re-organisation of the Pact Go docs helpful too - keen for feedback. These docs are super slick from a glance over. But also that README is :fire: ? looks great, sells pact quickly and straight to the point on how to implement. I can give feedback once I have had a better read. > FYI next week we?ll be publishing our August edition of the Pactflow POST (newsletter), and I?d like to include links to all of the work going on upgrading to v3 / rust integration I?ll respond to this in the other thread: https://pact-foundation.slack.com/archives/C0143ESUDB2/p1629418327016400?thread_ts=1629093651.006200&cid=C0143ESUDB2

I'm unsure I would prioritize null safety since it adds little value. I tend to use monadic structures to ensure type safety. I'm working on a type safe dsl for matchers and I'd like to finish it before migrating. Also I'm unsure if the dart package system allows me to have several active majors, say 1.0.0 (current)and 2.0.0 (null safe). Do you know if it is possible?

Just to close the loop on this: I noticed last night that I completely goofed the code that loads the dynamic library. I modified this and decided to require users to run an install script to obtain `libpact_ffi`: ```dart run pact_dart:install``` This installs `libpact_ffi` to the path `/usr/local/lib`. However, they can also set an environment variable, `PACT_DART_LIB_DOWNLOAD_PATH`, to choose the location (thanks `pact-go` for the inspiration). Users on Windows are required to provide this. I haven?t added much documentation on this at the current time but plan to this weekend. PR: https://github.com/matthewshirley/pact_dart/pull/3/files

ha!

I?m not sure if it?s possible to bundle the library with the dart package, but if possible, that is MUCH more preferable.

I?d do that with Go, but it?s not an option because that?s not a thing

Sadly, it?s not possible with Dart unless if using Flutter. :sob: It is as a requested feature: ? https://github.com/dart-lang/pub/issues/39 ? https://github.com/dart-lang/sdk/issues/36712

Friends, I've created #libpact_ffi-users - since there's quite a bit of discussion about the rust pact ffi bindings in the different language channels, but the discussions cover quite a bit of the same ground. Please join if this is useful or of interest to you!

has joined #pact-dart

Thanks, Matt. I noticed it in the FFI library and thought it was required although I don?t see it used in the generated Pact. I have removed the requirement to provide a description https://github.com/matthewshirley/pact_dart/commit/29ce2d86e3e5450792f8201f63df9aa7b9ce7eff. Edit: and fix for the https://github.com/matthewshirley/pact_dart/commit/bdc075691ffc7137da6a5d15f0feda2ac3f64a81.

Good call ? I can update this. I?m going to work on the README tonight because I need to document a couple of additions I recently added.

Thanks, that?d be great

If you could also look at getting the docs close to https://github.com/pact-foundation/pact-go/tree/2.x.x/ that?d be awesome too. Mailout is going to happen this week, so aiming to get lots of eyeballs (not sure how popular Dart is though - we?ll see!)

Sweet, I have updated the readme and started started with the documentation (plenty of control + v/c) for writing consumer tests.

I believe (but might be wrong) the interaction description is for describing the pairing - eg, "a request for betsy when she exists"

although, it's probably possible to construct them automatically from the rest of the information

The description is definitely necessary

the FFI interface has two ways of defining it thouh

has joined #pact-dart

has joined #pact-dart

Hi All, is it possible to do consumer testing on a flutter application using dart 2?

I've found some repositories but all of them works only with old dart versions

I saw this https://github.com/pak3nuh/dart_pact_consumer but not compatible with dart 2.15.

Ok I see there exists a fork that it is compatibilized: https://github.com/matthewshirley/pact_consumer_dart would be awesome if anybody around here can help me setting it up because can't make it work.

Hey @abdelior, I responded to your email, but just cross posting here as well. I should archive that repository because I never got it working for me. I recommend you use https://github.com/matthewshirley/pact_dart which is maintained by me. Could you let me know if that library works for you?

has joined #pact-dart

has joined #pact-dart

has joined #pact-dart

@tjones has left the channel

has joined #pact-dart

has joined #pact-dart

has joined #pact-dart

Hello @matt682, are you still developing the pact_dart library?

Hey @neokree :wave: I am but it has been a while since I have made a release. I pushed some commits to `main` last week to upgrade it to the latest `pact_ffi` release, and am updating the mismatch error handling so its more usable. There is also a pull request to add support for message pacts that I need to review. Hopefully a new release this or next week.

Cool! We are currently reviewing pact to be used in our system. If accepted by the company we will use your library and help with the development if necessary

Sounds good, @neokree. Let me know if there is any outstanding features that is needed for the adoption. I have used it at my current company for the past year with great success.

has joined #pact-dart

has joined #pact-dart

> Successfully uploaded https://pub.dev/packages/pact_dart version 0.6.0. I?ve pushed a new version of `pact_dart` to `pub`. This release requires everyone to use PactFFI v0.3.x. The library can be updated by running the install command again: `dart pub run pact_dart:install` A key change with this update was to improve messaging when an interaction was unable to be verified: ```Pact was unable to validate one or more interaction(s): Interaction Mismatch #1 Reason: Request was not matched (GET /alligators) Expected: - Expected query parameter 'nice' but was missing - Expected query parameter 'hungry' but was missing Interaction Mismatch #2 Reason: Request was unexpected Actual: GET /croc Interaction Mismatch #3 Reason: Request was missing Expected: GET /alligator ``` The next release is going to add support for message pacts.

Awesome! I was not aware this project was moving forward as it has - great stuff! How can we help evolve the functionality of this? e.g Creation of a maintainer guide - ?how to build a language??

Thank you! I noticed that a few people starred the project in the last month which gave me motivation to give the package some attention. I don?t want people installing out of date dependencies. :sweat_smile: > How can we help evolve the functionality of this? Great question ? a maintainer guide could be useful for listing references and prior art on how things should work. I do learn better by looking at examples, both `pact-go` or `pact-swift` are great references if I?m ever unsure on something. This may not be true for other contributors who need more background, though. A set of standard tests that should be implemented to prove the feature is ?ready? and any nuisances are addressed would be nice. I sometimes wonder if I have forgotten something?

cc: @yousafn :point_right: https://pact-foundation.slack.com/archives/C0143ESUDB2/p1668017564841839 (this is a scheduled post to remind me/us) @matt.fellows

has joined #pact-dart

has joined #pact-dart

has joined #pact-dart

has joined #pact-dart