Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brainstorming on what to add to the docs #36

Open
bethesque opened this issue Jan 11, 2018 · 12 comments
Open

Brainstorming on what to add to the docs #36

bethesque opened this issue Jan 11, 2018 · 12 comments
Assignees

Comments

@bethesque
Copy link
Member

bethesque commented Jan 11, 2018

Please put one point per comment, so we can use upvote counts to get an indication of what people are most interested in.

@TimothyJones
Copy link

TimothyJones commented Jan 11, 2018

  • Repository structure/ecosystem (can be hard to know which repository to report bugs against)

@bethesque
Copy link
Member Author

  • explain the pact specification at a conceptual level and update this with a link: "If you are writing tests on the Consumer side to a different language on the Provider side, you must ensure you use a common Pact Specification between them or you will be unable to validate."

@bethesque
Copy link
Member Author

  • add info on how to use matchers to their best effect (eg. as lax as possible in the response, stricter in the request)

@bethesque
Copy link
Member Author

  • Where pact fits into the API lifecycle (diagram that @mefellows has)

@bethesque
Copy link
Member Author

  • Clearer explanation upfront of the process in a language independent way

@bethesque
Copy link
Member Author

  • Remove unnecessary references to Ruby (though it's a good language for doing code examples in if we do need one, because it is quite readable)

@bethesque
Copy link
Member Author

  • Value proposition of Pact Broker, the Matrix, can-i-deploy

@mboudreau
Copy link
Contributor

@bethesque Could I suggest that the examples are done in Javascript? My reasoning being that Javascript is the most well known language and currently our most popular across all our languages. Since this is a consumer driven contract framework, I'd imagine Javascript would make more sense from the consumer standpoint. We could potentially keep ruby for the provider side if needed.

@bethesque
Copy link
Member Author

Using JS for the examples is a very reasonable suggestion.

@bethesque
Copy link
Member Author

  • Explain better how the pact is generated

@TimothyJones
Copy link

  • Improve the general introduction to contract testing? I think we already have this, but from the StackOverflow questions there seem to be some common misconceptions

(this is the same as my earlier comment, but I had two points in one comment)

@mboudreau
Copy link
Contributor

mboudreau commented Mar 9, 2018 via email

@YOU54F YOU54F self-assigned this May 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants