Additional capability to existing UI, windows/mac standalone application

[dineshbhagat]

This is an amazing product and grateful to all the contributors for their time and effort.

I have used mockserver in integration tests, and I was exploring more capabilities.
Correct me if I am unaware of certain features.

Use case: I was looking for a way to use mockserver as a standalone application without a need to write integration tests.
Like an offline windows app/macOs app/UI without a hosting service or signup requirement.
So I found mockserver_ui.

Existing UI is good for

• to observe logs
• to check active expectations
• to check logs related to request(including proxy)

The typical sequence for using MockServer is as follows:

1. Start MockServer
2. Setup Expectations
3. Run Your Test Scenarios
4. Verify Requests

But this takes a good amount of effort and time to setup.
For integration testing, we need to do it only once so not an issue,
But consider the case where developer has a need to integrate backend APIs or UI integration (before APIs are developed).
There exists solution with node.js, faker.js, json-server.

Describe the feature request It would be good if we have a capability to

• start mockserver from UI (Existing: various steps mentioned at here --> MockServer can be run:)
• Add,update,delete expectations (Existing: Java/Javascript/Rest API calls)
• proxy setup(Existing: configuring_sut.)
• Save/export/import above setup as a file(Existing: persisting_expectations)
• use above settings in integration tests

What you are trying to do This feature helps to use mockServer library in integration tests, in standalone application or export configuration from UI and use it in integration tests.

The solution you'd like Since every feature has REST endpoint exposed, it requires integration with existing UI and UX effort.
Not sure on whether existing UI can be ported to Windows/Mac app.

Describe alternatives you've considered I have explored mockoon, and using it.
There is similar app with above capability but did not used it. wiremock

[jamesdbloom]

I’m confused why would you need a native application the UI already works via the web? Can you not just use a browser on Windows or Mac? That is how many teams I know use the existing UI today. I’m not sure why allowing creation of expectations via the UI would help your workflow. Do you think you should setup expectations manually via a UI? Shouldn’t that be automated with code so it is repeatable, reliable and not subject to error prone manual steps?

To simplify automation you can already record interactions and generate either JSON or Java code. This can then be tailored as appropriate and used against MockServer. Can you please explain why this doesn’t meet you use case.

Can you please explain how would porting the UI from web to native helps with that use case?

There is no other mocking tool that shows what is happening in terms of received requests, proxies requests, existing expectations and why they are or are not matching.

[dineshbhagat]

Thank you for your time to review.

My comments inline.

I’m confused why would you need a native application the UI already works via the web? Can you not just use a browser on Windows or Mac? That is how many teams I know use the existing UI today.

I mean any of UI or Windows or MacOS App. Since UI caters across the platform, it is a better choice. I am not preferring one over another.

I’m not sure why allowing creation of expectations via the UI would help your workflow.

Cases where I do not need to write Integration tests or coding to setup expectations for the mockServer.
Like ad-hoc testing for any new API which we would like to mock and it need not be part of Integration tests.
Similar to what Rest Clients caters the need of developers. It is just a tool to test REST request(many other types like socket etc.), but to test request, we do not need to write a code, add URL, other parameters and make a request. On plus side those requests can be exported for multiple clients code(curl, java-okhttp, java-unirest, php, python etc.).

Do you think you should setup expectations manually via a UI? Shouldn’t that be automated with code so it is repeatable, reliable and not subject to error prone manual steps?

Yes, I do agree that we should setup expectations with code and it is the way to write tests.
I am not against coding way of setting expectations but in some of the cases it is good to have a mechanism to add expectations from UI, verify.
If require, we can export these expectations and share it with other developers or export it to file.
This opens multiple possibilities of features but those can be future enhancement.

To simplify automation you can already record interactions and generate either JSON or Java code. This can then be tailored as appropriate and used against MockServer. Can you please explain why this doesn’t meet you use case.

I have not used this feature but based on documentation, we will need to write code and fetch the interactions from the logs. Isn't this bit of a task for an ad-hoc type of requests? I google about this and found UI way to do the same here

Can you please explain how would porting the UI from web to native helps with that use case?

UI is fine, not require for an explicit native app support as mentioned before.

There is no other mocking tool that shows what is happening in terms of received requests, proxies requests, existing expectations and why they are or are not matching.

Yes, that is mockServer's advantage over other tools and we definitely need that.

[jamesdbloom]

I've added an item to the backlog to improve and extend the UI functionality.

This feature request has been accepted, new feature requests are prioritised on Trello, so closing issue in GitHub, only bugs or unaccepted feature requests will stay in GitHub, so that new feature backlog can be more effectively managed, see: https://trello.com/c/hiCEL2NP/190-extend-ui-functionality

However when this feature is implemented this issue will be checked so please continue any conversation related to this issue here.

[dineshbhagat]

@jamesdbloom hopefully this feature is prioritised 🤞 🙂