Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Geofencing feature file #181
Geofencing feature file #181
Changes from 20 commits
ddfc1d4
95bd04b
bb2df50
a5221b1
296c111
7507571
7b39f8a
de6e32c
a3d58ba
b806c65
422ca3c
0a37af2
368ac66
ce8b897
36ccd72
e1faaac
9e58ca3
7951305
104e848
ae9e8bc
62989db
ab8471f
e627cc9
88aed70
65919a0
7aafd88
fc4b480
ba17839
b9fd8c9
a2893a6
188c49c
38f1660
9fcd8f1
7d91a4a
f26f845
888f6ba
05186ee
91eb45e
cde7ad6
c449069
2e1fbae
2b337f7
7056453
bfe30d1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would set something like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlurien I'm not sure what that means.. The case is here, that instead of a specific request body here we explicitly shouldn't have a request body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlurien IMO As we are keeping request body everywhere for creation of subscription then it makes sense to showcase no request body required for get list ,get & delete method .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Saying that a request body is not available for an operation without request body is not needed, as we don't mention that query parameters are not available, etc. Only createSubscription requires it.
The suggestion for a client with subscriptions created is to tell the tester that this method should be tested for a client with subscriptions, otherwise the response would be [], which could be another scenario to test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I thought it's an equivalent to the empty body :-)
So basically a precondition, that already some subscriptions exist.
We could make 2 cases of it, one to return an empty list and one with subscriptions. Currently the evaluation is generic with "if any", but it could be more specific then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can split this into 2 scenarios one with
Given a client with subscriptions created
response is an array of items complying with the schema
other
Given a client without subscriptions created
response is an empty array []
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we wanted to test that event is received when the device enters in some area I would write it as:
Scenario: Events are received for a created subscription for area-entered event
Given an existing subscription to area-entered for a device and an area
When the device enters the area
Then an event is received in the subscription callback url
And the event request body complies with the schema at "/components/schemas/EventAreaEntered"
More scenarios could be added to test the other type of events
That's a minimum. An enhanced scenario should validate that properties make sense, authorization is according to the subscription sink credentials, etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comments as above