Twitter | Search | |
Mauri Edo
Software developer, Atlassian
3,138
Tweets
143
Following
787
Followers
Tweets
Mauri Edo Sep 19
Consider talking to as well :)
Reply Retweet Like
Mauri Edo Jul 15
Replying to @benswift
Thanks Ben and team for the opportunity, and congrats for pulling of such fantastic conference in such trying times :) Rock on!
Reply Retweet Like
Mauri Edo Feb 14
Replying to @DannyDainton
Thanks Danny! Current timezone is AEDT (Australian) but I can vouch for my friend’s commitment and flexibility if that one is not great 😉
Reply Retweet Like
Mauri Edo Feb 14
Twittersphere, a good friend is looking for remote quality engineering or nodeJS development roles. Any leads? Thanks!
Reply Retweet Like
Mauri Edo Dec 19
Reply Retweet Like
Mauri Edo 8 Apr 19
Replying to @soswow
Ahahahh
Reply Retweet Like
Mauri Edo 19 Dec 18
Replying to @msokola @BenSayersDev
Nice article, thanks for the plug!
Reply Retweet Like
Mauri Edo 23 Sep 18
Replying to @shekharsp27
Sorry no I don't, you should write it as an exercise!
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
Does this help? I hope so! Let me know!
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
A tool that approaches things this way is Swagger Mock Validator (). DISCLAIMER: I work on this one myself :)
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
An alternative to this all, write contract tests against mocks from consumers (A and B) and use tools that leverage the Swagger file of providers (B and C), so providers can validate consumers' expectations without spinning up themselves.
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
You could answer A's contract tests with B spun up with a mock of C, but then the chain of responsibilities perpetuates down, so in this case it's *crucial* that you write contract tests between B and C too, spinning B in isolation to request, and C in isolation to respond
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
... I can see how that might introduce flakiness, complicate setup and add coupling where a test might fail because of C and not B misbehaving. In this case, I would also consider the following:
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
B fetches the Pact file and gives it to contract testing libraries for them to reply the recorded requests from A against B itself. Here you want B to behave as close to reality as possible, so spinning up B with C is an option, however...
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
A writes tests against a mock of B, and when using contract testing libraries, the requests made from A and expected mock responses from B will be recorded onto a Pact file. You only spin up A here, the contract testing libraries do the rest.
Reply Retweet Like
Mauri Edo 20 Sep 18
Replying to @shekharsp27
Hey, great questions! IIUC, the chain is A consumes B, who consumes C, right? So in a full contract testing approach...
Reply Retweet Like
Mauri Edo 31 Aug 18
Replying to @rosiesherry
Smiling at your tweet, that's how I am :) I had a son! A year ago! Other than that, busy and still in Australia haha. How about you?
Reply Retweet Like
Mauri Edo retweeted
Dom Udall 改善 10 Jul 18
Contract testing for Microservices - getting pretty angry about integration and e2e tests, with good reason! Plus providing an alternative
Reply Retweet Like
Mauri Edo 29 Mar 18
(2/2) When the provider changes, before releasing a new API version, the provider uses Swagger Mock Validator to check its new API docs with the contracts against itself present in the broker. This way each side validates when they change, which is, when things can break.
Reply Retweet Like
Mauri Edo 29 Mar 18
Partly, but my fault for not being clear :) When the consumer changes, we use Pact to generate consumer contracts yes, and then use Swagger Mock Validator to check with the API docs of the provider before deciding if the new contract is worthy of going to the Pact broker (1/2)
Reply Retweet Like