I used WireMock extensively in a recent project that had a dependency on flaky REST API. Using the proxy/recording feature to quickly get some canned responses from the dependency allowed us to perform integration testing even though the dependency was frequently down...we basically mocked it away so we could have a reliable CI environment. Later on we were able to stabilize the dependency but we kept the mock service in several cases because it provided significant flexibility.
I tried using wiremock for mocking HTTP requests to our microservices' downstream dependencies. Rather than using a standalone wiremock server, we used the java lib. Periodically the connection would drop and our tests would fail. Switched to a standalone mock and haven't experienced this issue since.
We tried both Mountebank and Wiremock and opted for Wiremock as it had more features we needed. We run thousands of tests every time a developer commits and we see no problems using the Java API.
We did run into an issue a small when we parallelized our tests. After a certain parallel factor we saw what looked like Wiremock not being able to keep up. However this might be FUD and we were running these tests all on one machine including a docker-composed test harness so there were a lot of moving parts
Overall Wiremock is excellent. I really rate the functionality to attach state to scenarios. You can model quite complex behaviour with this
I was just about to come and post the same thing. It's hard to imagine it's not intentional, even the contrasting colors are similar and on the same sides. I'd think the authors may want to reconsider the logo as they have some commercialization of the tool (pro support.)
If anybody is looking for something similar, but with a user friendly GUI on top, and running as a cross platform desktop app, please checkout https://mocktastic.com
In addition to allowing you to mock multiple response codes for each endpoint and proxying and recording proxied requests, it also has a complete log of all requests and responses it handles that would be helpful for your debugging.
It also has team sync features so one person on your team can mock a complete REST API server and others can seamlessly use it.
EDIT: Currently it only supports mocking HTTP REST APIs. Support is planned for websocket messages and graphQL.
Looking at this, I can't seem to find any examples of Wiremock being used to test async callbacks, which is one of the more challenging things to get right. Can anyone point to some documentation or code samples showing how to do this in Wiremock?
I highly recommend it. I use it at a client extensively and have grown to rely on it heavily for its ability to provide a hermetic testing environment with mobile apps (android).
It can also test (de)serialization, parsing of HTTP headers, fallbacks, etc. When you're testing business logic then using a mock adapter would be fine, of course.
I've no idea why, but all of your comments were dead. I've vouched for them, so hopefully people will be able to see them now. Seems a bit silly to have the author in the thread, but all of his comments hidden!
More generally, it's useful for mobile development in the following scenarios:
* The back-end API you depend on isn't ready yet
* The back-end test server is slow, flakey etc.
* You want to test scenarios you can't easily make happen on demand like slow responses, 503 errors, dropped connections etc.
Worth mentioning that even if you're not driving WireMock from Java (or another language binding), you can run it on your laptop or a server from a bunch of JSON files. This makes it usable with e.g. iOS apps.
Alternatively you can use https://www.mocklab.io, which is 100% compatible, but hosted, has a UI etc.
While I can easily see how this can be part of frontend development workflow, enabling "frontend-first" app development, TBH, I fail to see how this tool can be helpful for testing purposes. Something like http://www.apilope.com/ or https://uptimerobot.com/ do test the real thing, rather than a simple collection of mock templates.
Two totally different tools/purposes. Wiremock is not used to test your web service, it's mocking the web service so you can quickly code up your client work.
In particular, this is useful if you will eventually be consuming web services which do not yet exist. You can quickly mock up some JSON/XML responses and hit them using real HTTP request and response.
Indeed, you rephrased what I was saying. I fail to see how wiremock can help you "testing" your infrastructure (frontend in this case), as opposed to be saving you time during development of interfaces (use case that I can see it useful for).
I'm afraid I may not clearly understand what you mean by "testing" then.
I worked on one project where we used Wiremock extensively. Development and QA was done against the mocks because the real target system did not exist yet. Everything from business logic to error handling and even load testing was done against wiremock. Even when the other system got up and running, some conditions were impossible to test without wiremock. For example, what if the web service we hit returns a 500 error? Well, the real system never did that in practice. But with wiremock we could do that whenever we wanted.
Of course, we still had to do integration testing before going live, but wiremock saved us a TON of time for development and QA.
"Development and QA was done against the mocks because the real target system did not exist yet."
Wouldn't this be frontend discovery/development, rather than frontend testing? In this case, I recognize the tool can be useful.
"For example, what if the web service we hit returns a 500 error?"
Isn't this what development and staging environments are for? Not trying to be polemic/destructive, I just see building and maintaining mock api templates as a further overhead, when specific backend behavior can be simulated in an alternative deployment environment once a backend is in fact there. But maybe I don't fully understand the constraints posed by workflows other than mine! :-)
You may not have any control whatsoever over the backend. You may not even have the ability to create data scenarios you want to test. Creating large/complex data scenarios is almost always more time intense than creating a mock. Honestly, creating simple data scenarios is almost always more time intense than creating a mock.
Can be very useful when your testing is troubled by permanently changing backend data or when some cases are hard to get examples of.
Imagine writing a front-end to a third party weather API: recording gets you repeatable examples and slightly edited copies of those recordings allow you to check unobserved extremes without manually mocking out the whole thing.
I'd love to see an index of who uses what. I see the who's using us section, and some of those names look familiar from other sections. So it'd be fun to flip things and show what any given company is using.
