https://pact.io logo
Join Slack
Powered by
Hey there, is there a recommended way to implement...
# pact-js
t
Hey there, is there a recommended way to implement a UI feature that relies on new fields/endpoints when developing consumer first? I've seen that there is Pact Stub Server but that might not be enough to get the application into the state to be able to develop a certain UI aspect. I think this is not necessarily pact specific, but I haven't found anything on this so far, maybe someone can point me into the right direction.
I currently assume this will require some changes in development style, in addition to or instead of using some specific tooling
m
We could possibly add some suggestions to our docs. The stub server can work pretty well in many cases
Alternatively, what we do, is create fixtures that we can use in both Pact tests and stubs. Personally, I like to work without any real dependencies locally and use stubs for such things. But the problem there is that your stubs may drift from reality. If you have a set of fixture files that you use in these stubs and re-use in your Pact tests, you now have the confidence to use them in development as well
t
Okay thanks. I tried to run the client application against the stub server last week. The largest barrier so far was that the stub server will only match requests that exactly match the specified request path and not recognise any parameters in the path. This is problematic if there are parameters (like a user id) that might not be actively controllable, but I guess that can be solved by changing the local development setup.
When I took a look at the stub server I immediately was reminded of https://www.mocks-server.org/ , which allows to explicitly set which collection (in case of pact which interaction) is active using the CLI or test framework integration. Maybe a cool feature for the future, but probably not trivial to implement.
m
Which stub server are you using, out of interest?
The one bundled with Node JS is the older one, this one might actually have what you need - https://github.com/pact-foundation/pact-stub-server
@Yousaf Nabi (pactflow.io) I think this is yet another argument to remove the CLI from Node JS, because it encourages both the old verifier and stub service to be used against our recommendation
Is this the concept you’re talking about? How does the user select the variant at runtime for e.g. integration tests? Does the test harness notify Mocks Server somehow (via CLI, API or the interactive CLI) in between tests to say “hey, use this variant next”? Or something else?
t
Yes I think so. I know that this is possible with pact stub server too, but only when launching, right?
Which stub server are you using, out of interest?
The one that can be run using npx. I think that's the ruby version that's downloaded by the js-cli
✅ 1
Mainly because it was installed anyway and the one you mentioned above seemed to require manual installation
👍 1
Yes I think so. I know that this is possible with pact stub server too, but only when launching, right?
I just remembered, probably collections are relevant too, which are basically a set of different variants activated. I think you can't actually activate individual variants, but only collections containing variants. But for the pact stub server it might be fine to just be able to enable and disable each interaction.
👍 1
m
Makes sense. The stub server I linked can be controlled via headers on the API call to dynamically select different states
👍 1
y
@Yousaf Nabi (pactflow.io) I think this is yet another argument to remove the CLI from Node JS, because it encourages both the old verifier and stub service to be used against our recommendation
Mmm yeah, I’ve thought this, especially as pact-js-cli will expose the api interface to those legacy interfaces (pact-mock-service / pact-provider-verifier / pact-stub-service) Now we’ve done work to reduce the size of the pact rust executables, we can look to provide side by side replacements for the rust/ruby. There was some thoughts in pact ruby standalone about how we could provide all in one place for the legacy and current tooling https://github.com/pact-foundation/pact-ruby-standalone/issues/8#issuecomment-1584936486 and hopefully the api can be over the pact rust cli tools.
nod hmm yes 1
Open in Slack
PreviousNext
Powered by