-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature for API retrieve #22
Conversation
Adding features require tests |
Additionally, tests will provide the use case and how to use it Thank you |
@lindycoder Sure, I will add. I'm not really familiar with Nosetest, however :( |
Nosetest has the exact same contract as unittest the built in python test framework. I was thinking about this feature and how to make it clean in the code, because the goal of this library is to present a simple an inuitive interface. If you want pure api implementation there's one coming that implements open api by James Bloom himself. So i wonder how you plan on using this feature but here's how i would probably want to it for inspecting generated content for example:
This is a rough draft but that's kind of the idea So the expect() method could return an expectation object that remembers the request() given and can use it to call the /retrieve. According to the https://app.swaggerhub.com/apis/jamesdbloom/mock-server-openapi/5.4.x#/control/put_retrieve it uses the same request matcher has the httpRequest param of the /expectations I'm open to suggestions |
Thanks, I think, I got the idea :)
The biggest problem here, is that I have no strong idea if this is a problem or not. |
According the api, they do that have the same signature in the content you post check this out : https://imgur.com/a/raCeAg1 So when doing a .expect you can save the request= param and us it in the retrive without having to copy the request content Also looking at your example it would probably make sense to have
Then your example would look like:
|
I need to think a bit more. There are some points about potential
If you want OOP here instead of imperative procedural paradigm, we need to pack everything to appropriate objects. |
Reading the /retrieve api i realised that only requests fetching is related to expectation, logs or record expectation retrieval should be topic handled on its own given the use case. If the format should change here i would create a .java() but i don't see how this could be beneficial in python so maybe we don't even need the .json and the expectation could have a @Property .requests that gets the requests. Now for your use case, i understand the path is a regex but the example you provided uses the same regex on the retrieval. The goal of this lib is to make beautiful elegant and readable tests... so when you way we need an OOP paradygm instead of procedural, i say : write the tests how you want it to look, then make it work. That's what generated the current structure, it doesn't need to be more complicated. So if i may suggest : Take your actual use case, make a test for it, make it pass and we'll see later if we have other needs. #agility :P |
Ok, I got it, thank you, Martin :) |
Closing this due to #26 actually seems much better, and I still can't get over myself to write tests for Nose :( |
Added a feature for API of mockserver to retrieve logged objects.
I've also seen a feature request for this thing in the repo.