You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the feature request:
This feature request proposes the ability to generate pacts off the back of Android automation tests that utilise a mock server.
Use case / for what or how I would use it:
OkHttp provides a MockWebServer to which a Dispatcher can be added. This MockWebServer, is as the name describes, a mock instance for receiving responses when running automation tests. The Dispatcher that is provided gives developers access to both the request that is made as well as the response that they are expecting. Given these two pieces of information, we could create pacts.
There are caveats with this suggestion however, and I don’t claim to have the answers. One of the blockers that stand out for me would be the mechanism of pulling the pact files to a project directory - the generated pacts described above would be stored on the device during automation tests.
I propose this feature after observing the overhead required to write pacts that cover each permutation that a request can take for a given endpoint. Considering that this information could already be available to developers when they introduce Pact to their project, this could make Pact adoption much easier.
I must have missed this idea, but the biggest problem is adding matchers. Without matchers, a provider side test with Pact might be painful. One option would be to just default to a like matcher, so that it just looks at shape.
This would work nicely, however, with the Pactflow bi-directional feature (https://docs.pactflow.io/docs/workshops/bi-directional)
Description of the feature request:
This feature request proposes the ability to generate pacts off the back of Android automation tests that utilise a mock server.
Use case / for what or how I would use it:
OkHttp provides a MockWebServer to which a Dispatcher can be added. This MockWebServer, is as the name describes, a mock instance for receiving responses when running automation tests. The Dispatcher that is provided gives developers access to both the request that is made as well as the response that they are expecting. Given these two pieces of information, we could create pacts.
There are caveats with this suggestion however, and I don’t claim to have the answers. One of the blockers that stand out for me would be the mechanism of pulling the pact files to a project directory - the generated pacts described above would be stored on the device during automation tests.
I propose this feature after observing the overhead required to write pacts that cover each permutation that a request can take for a given endpoint. Considering that this information could already be available to developers when they introduce Pact to their project, this could make Pact adoption much easier.
https://pact.canny.io/admin/board/feature-requests/p/allow-pact-generation-in-android-automation-tests
The text was updated successfully, but these errors were encountered: