It's a nice idea, but relying on a remote service for testing makes me worry. I tend to mock HTTP responses locally, so that the tests can run when there isn't even an internet connection available.
I use ruby [vcr](https://github.com/vcr/vcr) to mock responses. But ordinarily it 'records' an actual HTTP interaction, to play it back latter mock. If you want to mock something you don't currently have conveniently 'live' to record, you can try to write up the serialized recorded request by hand -- but it'd be a lot easier to use this service to mock up a request, then record it with VCR so subsequent test runs don't go out to the network.
Yes, you are absolutely right. But sometimes is a good idea to test somes WS requests across all the network, in addition of your locally mocked tests.
It's a neat idea but I can't imagine I'd ever actually use this for real testing. Relying on a third party server for your tests can be a problem. We also have thousands of tests that rely on mocked REST responses, setting them up with Mocky would be a ton of work.
If Mocky could be ran onsite and had a nice API for easily generating mock responses, then I think it would be more useful.
It's an open source project, created 2 days ago. All is possible, this website is just a proof of concept.
And you can fork the project to run it locally.
And internal to that system we have some components that understand the overall shape of our data model so someData can be a very small, simple object with just the data the test cares about and the internals flesh out the rest.
I use mocking framework(Moq for .NET) to mock my service response and various xml responses i will save in test xml files..
Anyways, I will try to use it to test over network rather local mocking
Been working on something similar for local use by running nodejs to both server static files and mock API responses. https://github.com/rco8786/apimok
Yea i'm not looking to obfuscate, I'm planning on introducing user accounts whereby people by create, save, edit, and alias their mocks. Bypassing that issue. Anonymous mocks will simply be sequential base62.
i'm using it on first project and it's very nice. they let you export your complete api definition to apiary.apib file which can be parsed with their github.com/apiaryio/blueprint-parser into json and used with your custom server localy. it's also nice for synchronizing between devs, when added to vcs ...
this isn't any better than using a live server for testing.
Build a good client library for your applications to use, mock the client library and don't worry about tests failing because of availability problems.
If the live server has side effects when making the call (send an email, charge a card, etc) and you just want to test against the response headers/body, it can be very useful. A local mocking library is also good for that, but for quicker tests this is nice.
Would someone provide an example on how this tool could be used to test a REST API? I think I'm missing something here. I'm not seeing how a fake response endpoint lets me test my REST API (shouldn't my test code invoke the API and validate that the real response was correct?)
One usecase I can think of is when UI developers are working on a set of expected response from an API while the API is currently being developed by backend developers. Once the API is ready, UI devs can swap the uri.
It seems to me that it isn't for testing a REST API but rather for testing something that depends on one without having to deal with real integration issues.
Your test code should invoke the real API if it's testing the real API. If you're testing a REST client, on the other hand, then it's best to unit test on a controlled set of requests and responses. Testing on the real API comes later, when you're doing integration.
57 comments
[ 4.3 ms ] story [ 64.9 ms ] thread"HTTP/1.1 500 Internal Server Error"
when that's not what I want.
I recommend this service for this kind of testing.
I plan to do some of that, as needed. Convenient.
If Mocky could be ran onsite and had a nice API for easily generating mock responses, then I think it would be more useful.
<div>what</div><div>Not</div>this<ul id="list" data-list="f"><li class="first">one</li></ul>
Full disclosure: I'm the author.
Build a good client library for your applications to use, mock the client library and don't worry about tests failing because of availability problems.