[zanata-devel] Testing clients and servers against each other with Pact

[Sean Flanigan]

On 2014-12-16 14:23, David Mason wrote:
> fake-zanata-server is intended for two purposes:
> 
> - To allow developers to work on clients without having to go through
> the significant hassle of deploying a Zanata server on JBoss locally.
> Someone can clone zanata-spa and run it while remaining in the
> context of the JavaScript build tools that are used to build the
> editor (installing node is the most manual part of the process).

> - To rapidly prototype additions and changes to the REST interface in
> a context that has very fast builds and a more straightforward way
> to declare the response bodies.

> How well does Pact fit each of these purposes?

From what I can tell, it is certainly intended to address both those
problems.  (As well as the problem of faked interactions not matching
real interactions with the server, naturally.)

I have only used pact-jvm, and only in consumer mode so far, not the
JavaScript version, but starting the test server was as easy as
specifying a port.

The response bodies can be created any way you like in the client
language.  I was initially using a hard-coded XML string, then I
switched to a fluent XML builder (Mycila XML Tool), and have now settled
on creating DTOs and serialising them via JAXB.

I have a pull request with my changes here:
https://github.com/zanata/zanata-client/pull/42


Enabling TDD seems to be a primary goal of CDCs, so I think it will
address the second point fairly well.

There's some information about the JS version's requirements here:
https://github.com/DiUS/pact-consumer-js-dsl

Oh, and in case you don't want to wade through a 70MB presentation, I
found a useful blog post about Pact:
http://techblog.realestate.com.au/enter-the-pact-matrix-or-how-to-decouple-the-release-cycles-of-your-microservices/



> The idea of recording interactions is interesting - if
> fake-zanata-server has continued utility that might be a useful
> addition. A quick search shows several Pact packages on npm, so it
> may be easy to add. Recording client interactions with the real
> server could provide useful information as well.
> 
> Cheers,
> 
> David Mason
> Software Engineer
> L10n Engineering
> 
> Red Hat, Asia-Pacific Pty Ltd
> Level 1, 193 North Quay
> Brisbane 4000
> 
> ----- Original Message -----
>> From: "Sean Flanigan" <sflaniga at redhat.com>
>> To: "zanata-devel" <zanata-devel at redhat.com>
>> Sent: Tuesday, 16 December, 2014 12:45:06 PM
>> Subject: [zanata-devel] Testing clients and servers against each other with	Pact
>>
>> Right now we have two different "pretend" versions of the Zanata server
>> (fake-zanata-server for JavaScript and stub-server for Java).  That's
>> not even counting GWT's old dummy mode - is anyone using this now?
>>
>> These dummy servers are taking up a fair amount of development and
>> maintenance, but how much do they really tell us about the interaction
>> between our clients and the real Zanata server?  And how much
>> maintenance effort will they require as the server changes?
>>
>>
>> Consumer-Driven Contracts[1] come up a lot when discussing
>> microservices, but given the number of clients for Zanata server -
>>
>>  - Java (current and old versions)
>>  - Python (current and old)
>>  - JavaScript - Zanata SPA
>>  - clients written by others (eg PHP client, OpenStack integration)
>>
>> - I think we could really benefit from using CDCs right now.
>>
>> One of the microservices talks[2] at the YOW! conference included
>> mention of Pact [3][4] by REA, which enables sharing of CDCs between
>> client and server for HTTP services.
>>
>> Beth Skurrie talked about Test Symmetry, which involves unit testing a
>> consumer against a mock [like fake-server or stub-server], but
>> *recording* the interactions to a pact file, then *verifying* the
>> interactions in the pact file (or files) against the real provider.  I
>> think this is a great idea, and a really important one.
>>
>> Before putting much more effort into our fake servers, I really think we
>> should try out Pact for Java [5] and/or for JavaScript [6].  It's
>> possible there will be a bit of a learning curve, but I think the
>> pay-off will be worth it.
>>
>>
>> [1] http://martinfowler.com/articles/consumerDrivenContracts.html
>> [2]
>> http://yowconference.com.au/slides/yow2014/SkurrieBottcherEvans-MonolithsToMicroservices.pdf
>> [3] https://github.com/bethesque/pact-specification (the spec)
>> [4] https://github.com/realestate-com-au/pact (the original)
>> [5] https://github.com/DiUS/pact-jvm (Java)
>> [6] https://github.com/DiUS/pact-consumer-js-dsl (JavaScript clients)
>>
>> PS ThoughtWorks has a similar library called Pacto, but I think Pact has
>> more momentum, with a spec and implementations for multiple languages.
>>
>> --
>> Sean Flanigan
>>
>> Senior Software Engineer
>> Engineering - Internationalisation
>> Red Hat
>>
>>
>> _______________________________________________
>> zanata-devel mailing list
>> zanata-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/zanata-devel


-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/zanata-devel/attachments/20141217/7d1eedb0/attachment.sig>