-
Notifications
You must be signed in to change notification settings - Fork 40
Home
It’s a Java web application, a .war (or executable .jar) file that runs in a servlet container. It was built to help reduce the constraints of working with services, services being other applications your app may be interacting with over http/https.
For more insight on its purpose, read http://blog.rufiao.com/2009/08/impersonator-pattern/ and [[http://www.martinfowler.com/bliki/SelfInitializingFake.html
]]
Here are some videos:
- Intro to Mockey https://vimeo.com/58502864
- Working with Mockey Services set to Dynamic
Point your application to Mockey and then point Mockey to the 3rd party application. With Mockey in the middle, it will capture all the messages being exchanged between applications. After enough messages have been captured, make Mockey the end-point and explicitly tell it what messages to return.
The cool thing is, you are no longer constrained by the 3rd party service to develop and test your code.
Here are a few reasons that made us build this thing:
- Client heavy application development. Examples like single page apps in HTML with lots of JavaScript or native application development like iOS or Android. Mockey could be your sandbox, representing your production or QA server environment.
- Consuming 3rd party web services. A web service can change state or be temporarily unreachable or unstable.
- Dynamic flows. Depending on the data being consumed, you want to test all your flows but the service provider doesn’t have all possible scenarios you need to test your application.
- Sandbox. The service you’re consuming isn’t always available, e.g. a development or testing service. Or, the service data state is unknown.
- Message inspection. The application is not working properly. Is it you or the 3rd party?