Provide a way to feed/register mock expectation(s)
Closed this issue · 8 comments
It would be great if we can place some (YAML) mock definitions in a specific path and Smocker will pick up those and register them.
Can you explain what you have in mind, for me it could match two different use cases:
-
To launch the Smocker service with mocks already configured, but it seems rather useless to me since they will be wiped on the first reset and you can easily setup all your mocks with a single HTTP call.
-
Using that to define a kind of "reset proof" mocks that will be set by default on every session allowing you to setup an easily resettable test environment which seems more interesting to me.
@Thiht do you have an opinion about this ?
What I'm trying to avoid is to have to put up a small application with an HTTP client in order to send the mock definition(s) to Smocker every time it's started from scratch. The workflow I currently have is using Docker, so I'm thinking: why I can't just put several YAML files somewhere in that Docker image/container and be done with it without using another container to provision Smocker? Probably not a concern of Smocker, but that's up to you to decide because the RESTful (admin) API does indeed the job.
I think that at start-up time Smocker can read a location somewhere in the file-system (probably configurable or even fixed) and seed the mock definition(s) found there.
I get the idea, but I'm not sure it fits with some of Smocker's features. The problem with specifying a startup path is that it raises a few questions:
- what do we do on reset?
- what do we do when a new session is created?
I don't really know your workflow, but in your case I think integrating a curl command to populate the mocks would be the most appropriate solution :)
I'd rather keep Smocker controlled by the API only as much as we can to avoid surprises.
I would recommend to take a look at Initialization & Persistence Configuration from MockServer; this is a very useful feature.
We were investigating using this (it's great btw, nearly perfect) for a large majority of our API testing.
However, if the service fails, regardless the cause, then all mocks are lost. We then would need a script to pull all the various mocks from SCM, and repush them to Smocker.
Today, this service plays a very temporary role in the development lifecycle, but what I and others here seek is to make it a persistent integration, rapidly reducing regression testing and continued development.
I understand you need but as @Thiht asked, we need to answer the questions raised by specifying a startup path:
- what do we do on reset?
- what do we do when a new session is created?
If your need is to be reboot proof, we can instead sync sessions on file system and reload them on boot. According to that at start Smoker would load the sessions and sync them on disk on each modification.
Currently, in our way of using Smocker, we create integration tests and mocks using it locally then it's our CI which start an instance in order to launch them. We do not use Smocker as a shared service which can fail because we start it, we run the tests on it, export the sessions, upload them as artifact (in order to be able to debug locally) and after that we kill it.
That's why we haven't encountered this kind of concern yet.
But we plan to use it as a dev gateway in the near future, so I think that synchronize sessions within the file system is not a bad idea.
To answer your questions.. I feel as these should be configurable, with your file system sync as the default. For me, I'd want to be able to configure as follows..
- Synchronize data to disk
- Synchronize only the newest session to disk
- On reset, load from disk
- On reset, load only the most recent session from disk
- Number of sessions to retain on disk
This asks whether it should be all together, or just this session.. but why not do it at the mock level? You could provide a parameter to store that specific mock on disk.
Want to get crazy? You could even provide a UI flow to load in the stored mock/session/instance..