Pact mock

The 2015 edition of CraftConf ended a few days ago. One of the talks I was eager to listen to was Mary Poppendieck (Poppendieck.LLC) - The New New Software Development Game: Containers, … If you haven’t seen it yet, please do. It’s an hour which is well spent.

One of the topics Mary mentions is the pact mock. The pact is an intelligent recorder and player which lets you to turn your integration tests into tests that look like integration, but using prerecorded request-response pairs. The funny thing is that this hits the very same topic I was presenting and discussing in my current project.

I’m dealing with a legacy project right now. It includes VB.NET as well, so yes, this is a real legacy;) There are some web services on board. Yes, I mean good old-fashioned SOAP services, not the brand new, fancy REST or HATEOAS. How would you test this interaction? Would you put a layer or mock the services? My proposal was differ ent from mocking the service. I thought that, if I setup a local server, just for sake of running tests, and record responses upfront, I could have a pretty highlevel, but still not integration level tests, which could help me to seal functionalities during the transition process to a new architecture. It’s similar a bit to the pact mock but still, do I really need a library for sth like this? A standard Fiddler + HttpListener can work just fine as well. Yes, the validation of the dependency against the recorded dialogue is hard to impossible, but still, what one gets is an easy way of testing your app without placing mocks all around the tests.

Even if you follow the pact mock path till the end, it’s worth considering that instead of dealing with mocks’ setup one can get the conversation recorded easily (just run your app) and reuse it later on. It may be not the unit test, but it can be the best test one can write being given the condition of communicating with other services.