Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

true3HAK
Copy link

Added a feature for API of mockserver to retrieve logged objects.

I've also seen a feature request for this thing in the repo.

@lindycoder
Copy link
Contributor

Adding features require tests

@lindycoder
Copy link
Contributor

Additionally, tests will provide the use case and how to use it

Thank you

@true3HAK
Copy link
Author

@lindycoder Sure, I will add. I'm not really familiar with Nosetest, however :(
I used to pytest, so it'll take some time. Thank you!

@lindycoder
Copy link
Contributor

lindycoder commented Mar 13, 2019

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:

expectation = self.client.expect(
    request(path="/path"),
    response(code=200),
    times(1)
)

request.get("...", json={"generated": "value"})

self.assertEquals(expectation.calls(0).json, {"generated": "value"})

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

@true3HAK
Copy link
Author

Thanks, I think, I got the idea :)
BTW, that's how I use the forked version:

  1. Setting up the expectation, so mockserver doesn't answer with 400
        # Expect items to be sent
        mockserver_client.expect(
            request=request(method='PUT', path=r"\/procurements\/\d+\/phase1\/items"),
            response=response(code=200)
        )
  1. Then, retrieve caught request:
        sp_notification_phase1_items = mockserver_client.retrieve(
            obj_type=RetrievedObjects.requests.value,
            response_format=RetrievedFormat.json.value,
            body={'path': r"\/procurements\/\d+\/phase1\/items"}
        )
        decoded_notification_phase1_items = json.loads(sp_notification_phase1_items.content.decode())
  1. Finally, check retrieved objects
from hamcrest import assert_that, is_not, empty
assert_that(decoded_notification_phase1_items, is_not(empty()))

The biggest problem here, is that retrieve method doesn't comply to signatures of other methods (like stub, verify), 'cause is works different – in my case I don't verify anything server-side (mocker-side, ofc), just "drag out" and then check in a test.

I have no strong idea if this is a problem or not.

@lindycoder
Copy link
Contributor

lindycoder commented Mar 14, 2019

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

class Expectation:
    def __init__(request):  
        self.request = request
    def get_requests() -> Retrieval()
        return Retrieval("requests", self.request)

class Retrieval:
    def __init__(type, request):
         self.type = type
         self.request = request

    def json() -> List[dict]:
         requests.put("/retrive....&type=self.type&format=json)

Then your example would look like:

expectation = mockserver_client.expect(
            request=request(method='PUT', path=r"\/procurements\/\d+\/phase1\/items"),
            response=response(code=200)
        )

requests = expectation.get_requests().json()

assert_that(requests, is_not(empty()))

@true3HAK
Copy link
Author

I need to think a bit more. There are some points about potential Expectation object.

  • If expectation doesn't equal to retrieval, how to provide them?
    For example, my retrieval path depends on data, which I don't have at the moment, where I set up an Expectation.
  • What if one wants other objects to be retrieved? I mean, not a JSON, or not a log, but recorded expectation.

If you want OOP here instead of imperative procedural paradigm, we need to pack everything to appropriate objects.

@lindycoder
Copy link
Contributor

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

@true3HAK
Copy link
Author

Ok, I got it, thank you, Martin :)
I'll find some time on the weekend and will finish this then.

@true3HAK
Copy link
Author

true3HAK commented Sep 7, 2020

Closing this due to #26 actually seems much better, and I still can't get over myself to write tests for Nose :(

@true3HAK true3HAK closed this Sep 7, 2020
@true3HAK true3HAK deleted the feature_retrieve branch September 7, 2020 13:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants