Detailed test plan for QoS Booking by jlurien · Pull Request #70 · camaraproject/QoSBooking

jlurien · 2025-10-28T12:04:42Z

What type of PR is this?

enhancement/feature
tests

What this PR does / why we need it:

Creates a new version of the test plan, substituting the single file that we had in the last meta, with a level of detail similar to what we have in other CAMARA APIs and aligned with the guidelines.

There is a separate file per operation, covering all expected responses. Comments are included when issues with the current spec are detected, which may be treated separately.

Which issue(s) this PR fixes:

Fixes #69

Special notes for reviewers:

Once merged, this test plan should evolve and be aligned with the API spec towards the next version.

Changelog input

- Enhanced test plan for QoS Booking API

github-actions · 2025-10-28T13:47:37Z

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Errors	Elapsed time
✅ ACTION	actionlint	2	0	0.01s
✅ API	spectral	2	0	3.85s
✅ GHERKIN	gherkin-lint	5	0	1.81s
✅ REPOSITORY	git_diff	yes	no	0.01s
✅ REPOSITORY	secretlint	yes	no	0.61s
✅ YAML	yamllint	2	0	1.07s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

Masa8106

Thank you for creating this PR.
Overall, it seems good. As there is several open questions, let us discuss them (Please find my comments.). Thank you.

Masa8106 · 2025-11-13T12:03:39Z

code/Test_definitions/qos-booking-createBooking.feature

+      | $.sink                   | exists only if provided in the request body and with the same value                                       |
+
+    # Open questions:
+    # serviceArea has to have same value as in the request body or implementations can make adjustments


Could you elaborate what you assume "implementations can make adjustments" is? Is there possibility that different serviceArea value with in the request body may be responded?

It's whether the value in the response has to be strictly the same as in the request or implementation may adjust the serviceArea to facilitate the implementation. I assume that it should be the same, but it would be good to make it more clear in the spec.

I understood what you pointed out. In my opinion, the same value would be better. But I became to recognise that implemantation may response different serviceArea value through breakout session. Therefore, it seems to be ok that there is no $.serviceArea in examples of the scenario outline.

How should we handle this?
(1) We assume it should be the same: Write it out in the spec and adding $.serviceArea as example.
(2) We allow implementation adjust the serviceArea: (Write "should be the same" our in the spec, and approve this as it is).
My preference is (2). What do you think?

Masa8106 · 2025-11-13T12:22:35Z

code/Test_definitions/qos-booking-createBooking.feature

+
+    # Open questions:
+    # serviceArea has to have same value as in the request body or implementations can make adjustments
+    # startTime has to have same value as in the request body or implementations can make adjustments, to be returned when status = UNAVAILABLE?


Same comment with the above. And it is good question regarding a response when status = UNAVAILABLE.
I think startTime shold be returened even when status = UNAVAILABLE if the booking is created. Because status can be changed to Available at the startTime, even if the status is UNAVAILABLE at the time of booking.

Same response, e.g. if the request is to start at 12:34:56.789, may the implementation make adjustments to e.g. the nearest second or the returned value must be exactly the same value.

With respect to UNAVAILABLE, the spec now says:

If the operator determines synchronously that the booking request cannot be fulfilled, the response will be 201 with status = UNAVAILABLE.
so currently a response with status = UNAVAILABLE means that the booking is not created and it cannot evolve to AVAILABLE at startTime. When the booking is created the status must be SCHEDULED.

Regarding with UNAVAILBLE status that is also related to the next comment, I feel that update of the status diagram, which is created in our very initial discussion, is needed for our clarification.

Masa8106 · 2025-11-13T12:27:41Z

code/Test_definitions/qos-booking-createBooking.feature

+    # startTime has to have same value as in the request body or implementations can make adjustments, to be returned when status = UNAVAILABLE?
+    # duration to be returned when when status = UNAVAILABLE?
+    # bookingId to be returned when when status = UNAVAILABLE?
+    # statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string


We can discuss on this. There is status diagram I assume so far here.

I commented about this above. In the diagram that you link there is no status for a booking request that has been declined, but the v0.1 spec says that the status for a booking declined during creation is UNAVAILABLE. That is something that we need to decide upon.

See the above comment.

Masa8106 · 2025-11-13T12:32:20Z

code/Test_definitions/qos-booking-createBooking.feature

+    # duration to be returned when when status = UNAVAILABLE?
+    # bookingId to be returned when when status = UNAVAILABLE?
+    # statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string
+    # sinkCredential may be returned in the response in any case or it should be removed for security


I think it is good way to align with other QoD APIs on how sinkCredential is returned.

Agree. Even more, it should be aligned at Commonalities across all CAMARA APis

As far as I see QoD API and QoS Provisioning, sinkCrediential in the response is not specified, I think, due to security reason. I prefer to keep as it is (I mean no sinkCredential should be returned).

Masa8106 · 2025-11-13T12:34:11Z

code/Test_definitions/qos-booking-createBooking.feature

+
+  # This step is optional, for cases when the implementation did not grant the booking synchronously and later rejects the booking
+  # or when it was granted (SCHEDULED) but implementation decides to revoke it before the start
+  # TBD if a better status or statusInfo is specified for this use case, e.g. status = "REJECTED" or status = "UNAVAILABLE" + statusInfo = "NOT_SCHEDULED" or "REVOKED"


We can discuss on this. There is status diagram I assume so far camaraproject/QualityOnDemand#337.

as commented above the v0.1 is not aligned with that diagram, so we have to work towards v0.2 on a better definition of statuses in the spec, which is what prevails.

code/Test_definitions/qos-booking-createBooking.feature

Detailed test plan for QoS Booking

bb79f93

jlurien requested a review from Masa8106 as a code owner October 28, 2025 12:04

Merge branch 'main' into qos-booking-testplan-evolution

4286176

jlurien added 2 commits October 29, 2025 09:58

Linting error fixtures

cd6859e

Reduce long scenarios size

ae4df5b

Masa8106 reviewed Nov 13, 2025

View reviewed changes

hdamker requested a review from Masa8106 December 12, 2025 12:36

Conversation

jlurien commented Oct 28, 2025

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for reviewers:

Changelog input

Uh oh!

github-actions bot commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦙 MegaLinter status: ✅ SUCCESS

Uh oh!

Masa8106 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jlurien Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jlurien Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions bot commented Oct 28, 2025 •

edited

Loading

jlurien Nov 13, 2025 •

edited

Loading

jlurien Nov 13, 2025 •

edited

Loading