Geofencing feature file

[mdomale]

Geofencing feature file

What type of PR is this?

Add one of the following kinds:

• tests

What this PR does / why we need it:

This PR is required for consideration of Feature file for Geofencing which includes all possible test scenarios

Which issue(s) this PR fixes:

No specific issue available currently

Fixes #211

Special notes for reviewers:

Feature file with test scenarios

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[mdomale]

@akoshunyadi @shilpa-padgaonkar @hdamker FYI

[jlurien]

Please @mdomale, edit the template with the right values

[mdomale]

@jlurien Added required details .Please let me know in case any further details are anticipated

[jlurien]

The test plan should test the scenarios listed in the guidelines for explicit subscriptions model:

For the explicit subscriptions model:

• Validate that the subscribed events are received in the sink, with the right sinkCredential, for those situations specified in the API.
• For subscriptions that provide subscriptionExpireTime, validate that the subscribed events are not longer received after the expiration time.
• For subscriptions that provide subscriptionMaxEvents, validate that the subscribed events are not longer received after the maximum events limit is reached.
• Validate that after a subscription is deleted, the subscribed events are not longer received.

The level of detail should be also in line with the guidelines. In general we need to be more precise about the Given steps to fill the request in order to generate the expected responses, and check also that the response object is the correct one, against schema or with some specific validation, not just the status code. Take a look to the examples for the other 2 APIs already merged.

[mdomale]

Updated

[jlurien]

I still think that indicating that a request body is not available for operations that do not consider it is confusing. Moreover using the term "available", in that case even "request body is not sent" or "request body is not included" would be better options (but still no needed)

The rest of the proposal now seems quite acceptable to me. Thanks

[jlurien]

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

[mdomale]

@jlurien @bigludo7 PR updated with required changes cc @akoshunyadi

[jlurien]

Suggestions ready to remove the unneeded references request body for get and delete, as applied already at the beginning.

[mdomale]

@jlurien @bigludo7 PR updated with above suggestion cc @akoshunyadi

[jlurien]

LGTM, thanks @mdomale and @akoshunyadi :) @bigludo7 please take a last look

[bigludo7]

Thanks a lot @mdomale for the effort.
LGTM now