Multiple mappings per .json file.

[Zachariah Kendall]

From what I can tell, WireMock doesn't support having multiple mappings per json file. It'd be nice if a json file could have a [ {} , {} ] list of mappings. Is this something that you'd consider?

My use case is that we're mocking multiple services throughout a system for our build-acceptence-tests. So then we pass through various customer identities that each need many mappings. So we have a ballooning of mapping files SuzieService1.json, SuzieService2.json, etc. Most of these are simple mappings and it'd be nice to collapse them into a single file.

[Tom Akehurst]

If you wanted to raise a PR for it, I'd happily merge it. I've got a fairly large backlog of stuff to work on myself though, so as a feature request it might take a while to arrive.

Might I humbly suggest though that if your mapping files are ballooning, then that's probably an indicator of bigger problems looming down the line. Putting multiple mappings per file would hide this, and this was the main reason I didn't do this in the first place - I wanted to discourage my team members from generating hundreds of similar stubs that'd present a maintenance nightmare later.

If stubbing on the fly from within your test code is an option, I'd suggest switching to this and writing builders to generate the appropriate test data. I've found through experience that the up-front investment is well worth it in terms of reduced maintenance over the long term.

Out of interest, what kind of setup do you have? Is WireMock running standalone on a server, or embedded into your test code?

[Zachariah Kendall]

We use both. For project unit and integration tests, we use embedded WireMock.

Then we have an acceptance test development environment with dozens of services running in integration. Some of these make external service calls in production which we can't make in development, so we have a standalone wiremock service. When one of our project artifacts is build in Jenkins it is deployed to this dev-test environment, and a set of build-acceptance-tests are run,. These BATs hit services which hit services which hit wiremock with customer names that trigger specific mappings. So I guess the bottom line is we have a multi-service deployment that is integrated as it would be in prod, except it can't hit some external services that it would in prod.

[Tom Akehurst]

OK, this is interesting. Apologies for taking the thread slightly off topic, but would you be willing to have a 30 minute Skype chat about this?

The reason I ask is that I'm researching the possibility of building a complementary (possibly SaaS) product to WireMock aimed at the second use case you described (i.e. multiple deployments in a test environment). One of the key problems I'm interested in attacking is the management of large stub sets. Since you're clearly working at a scale where you're hitting these issues, I'd be very interested to get your insight.

[Zachariah Kendall]

Yep. Most days around 6PST would work for me.

[Tom Akehurst]

Thanks, appreciate you getting back to me.

Unfortunately I'm 8 hours ahead of you so I'll have to try and find an OK moment to pull a late one.

[Zachariah Kendall]

I can do earlier on the weekends.

[Tom Akehurst]

Would this Saturday or Sunday be any good for you? Any time in your morning would probably work for both of us I guess.

[Zachariah Kendall]

This weekend wont work. I'll be out camping.

--
You received this message because you are subscribed to a topic in the Google Groups "wiremock-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wiremock-user/GQCGLoZlWEk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wiremock-use...@googlegroups.com.
To post to this group, send email to wiremo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/wiremock-user/d1aad60a-df5a-4f1c-84d2-1860ea5af9e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Akehurst]

Ok, no worries. Perhaps you ping me next time you've got an hour to spare on a Saturday or Sunday morning?

[talisker25]

Hi guys, 

We have a very similar scenario as Zachariah was describing in the original post. It would be handy for us to combine mappings related to a given scenario in a single json file. We would then have as many "scenario" json files as required. 

Was this feature added to the backlog in the end? Is there an issue # I could track?

Many thanks

[Tom Akehurst]

There isn't a GH issue for this at present. Happy to mark one as a feature request if you'd like to create it.

[Dalton Robertson]

I was wondering if there are any update on this issue?  I am currently working with Wiremock and have some service calls where there are multiple ways to reach a payload and was hoping to not have to duplicate the mappings for each path.

[Tom Akehurst]

That sounds like a slightly different problem to me. And when I've encountered that problem in the past, I've used the DSL to configure stubs rather than files. Is that an option in your case?

[Dalton Robertson]

We have only been using JSON so far as for mapping these files and haven't done much with DSL yet. Can you provide an example of using DSL with stubbing? 

Thank you for your timely response! 

[Tom Akehurst]

All the examples in http://wiremock.org/docs/stubbing/ are given both as JSON and the DSL.