Windows Support to get all pact files in a directory

minhdoan159 commented 6 years ago

I am using pact-stub-server version 1.54.3 on Windows 10. I want to start stub-server and load an directory which contains about 100 pact records. I execute the command: pact-stub-service.bat "D:\pact\pacts\*" or pact-stub-service.bat "D:\pact\pacts\" but nothing happens. Try with: pact-stub-service.bat "D:\pact\pacts\pact1.json" "D:\pact\pacts\pact2.json" The server is up and the info of two pact files is loaded. But if applying this approach, the command line is too long and difficult to handle Please help to clarify if any option to input a directory only, or should have an enhancement for it? Many thanks and hope this grows fast!

bethesque commented 6 years ago

Can you help me understand your use case better? Why are there so many pacts for the same stub service?

minhdoan159 commented 6 years ago

Of course, @bethesque . My use case is we wrote the pacts agreed between a consumer team with provider team which developed web service. We want to bring up a mock server with the defined pacts, in order not to wait for web service team development progress. So the mock server should contains all pacts. Is it clear?

bethesque commented 6 years ago

No - I don't understand why there are multiple pacts? Did you hand code the pact files?

minhdoan159 commented 6 years ago

As our project work, each pair of request/response will be defined to a pact record, a json file and published to Broker with a unique url, e.g: http://pact-broker.mydomain.kfs.com/pacts/provider/PROVIDER1/consumer/CONSUMER1/latest And a consumer team need about 100 requests for this team. So we define about 100 pact records. We use pact-jvm-consumer-junit and write the consumer side test to create Pact record. Any mistake in this approach?

bethesque commented 6 years ago

Yes, you are very mistaken. I think you need to do some more reading to understand how Pact works. Have you read this? https://docs.pact.io/readme#how-a-pact-test-works (in particular the "Consumer testing" section)

Some important things to understand:

An interaction consists of a request and a response.
A pact is made up of multiple interactions. (So you should have one pact file with 100 interactions, not 100 pact files).
A pact file is generated from the consumer tests.
The mocked responses are set up on the mock service dynamically during the consumer tests by the Pact DSL in the language that you are writing your tests in.
You can use the pact-stub server with an existing pact file in later "full stack" tests, but the entire point of Pact is that the contract is generated by tests (preferably unit tests) in the consumer. https://docs.pact.io/faq#can-i-generate-my-pact-file-from-something-like-swagger
A pact file (with its collection of interactions) gets published to a pact broker as one artifact - it contains all the interactions that have been tested as part of the test suite.

Please make sure you fully understand this - your current approach is not at all correct, and will not work.

mefellows commented 6 years ago

That being said, do we still think there is value in reading multiple pacts from a directory?

bethesque commented 6 years ago

I don't see the use case in normal operation. If you are using your own pact file to run up a stub server, then there should only be one file. If you want to stub a production version of the server from the pact broker, you would only use one file. You wouldn't stub the behaviour of the service at more than one point in time.

minhdoan159 commented 6 years ago

I have read at the first days i investigated Pact. But as our discussion, if we made up a very long pact file with many interactions, maybe up to hundreds interactions, it is so difficult to read and identify which interaction to retrieve for each test case if the description is not clear. So we organize our pact as below: Broker: .pact.kfs.com, each consumer have a sub-domain, it meant a separate Broker url which contains all pacts of that consumer In that Broker, we write each pact with the convention as: Provider name: feature name Consumer name: test case of this feature And each pact only contains one or two interactions. We want to keep pact file concise, in order to apply tag and version easier in the future. When executing pact verify, it is easy to keep track the result of test suite, failed tests will be identified faster. Each line in red color on Broker is a failed test case. Clearly that the approach you provided has valuable when applying in development and mocking installation. But from testing pov, i think our way still have value. Please help to provide your idea about it so i have more lessons and best practices to apply in my work!

Many thanks @bethesque and Pact community!

mefellows commented 6 years ago

I can understand that pain point. Which language etc. are you using? Perhaps we can work to make that less painful and remove those workarounds.

minhdoan159 commented 6 years ago

@mefellows Many thanks for your understanding! I am using Java, pact-jvm-consumer-junit to write Pact records, and pact-jvm-provider for Provider test. Any suggestion is highly appreciated. However, the main point i wanna resolve here is bring up stub server with many pact files 💃

bethesque commented 6 years ago

I am amazed at your set up. It's not the "right" way at all but I can see why you're doing it that way. I'll make the change you want.

minhdoan159 commented 6 years ago

Many thanks for your understanding @bethesque . Because we are newbie on Micro-services, we learn days by days. Love Pact!

bethesque commented 6 years ago

Try v1.55.0 of the standalone

mefellows commented 6 years ago

@uglyog want to weigh in on https://github.com/pact-foundation/pact-mock_service/issues/94#issuecomment-416447663? Is there a way to address the provider verification issues described above?

uglyog commented 6 years ago

I might be missing something, but I didn't see anything relating to provider verification issues. From what I can tell, the main issue is visibility in the broker on what interactions failed.

mefellows commented 6 years ago

Yes, sorry, I really shouldn't skim issues and multi-task...

When executing pact verify, it is easy to keep track the result of test suite, failed tests will be identified faster. Each line in red color on Broker is a failed test case.

On Tue, Aug 28, 2018 at 6:53 PM Ronald Holshausen notifications@github.com wrote:

I might be missing something, but I didn't see anything relating to provider verification issues. From what I can tell, the main issue is visibility in the broker and what interactions failed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pact-foundation/pact-mock_service/issues/94#issuecomment-416504302, or mute the thread https://github.com/notifications/unsubscribe-auth/AADSjBJTJv99hgnIVwITfdp9-S-EP8jRks5uVQUAgaJpZM4WNl42 .

-- Matt Fellows

http://www.onegeek.com.au/

minhdoan159 commented 6 years ago

Thanks @bethesque so much! version v1.55.0 works well for my case, i can load all pact files to stub server with command: pact-stub-service.bat D:\pact\pacts -p 8081

bethesque commented 6 years ago

We've got plans for improving the visibility. Sorry you have to do such a complicated work around.

pact-foundation / pact-mock_service

Windows Support to get all pact files in a directory #94