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?

Maybe it is more problematic to allow implementations to modify the requested area in 2xx responses, because customers may complain that the booked session is not what they asked for. I guess that a very minimal adjustment would not be a problem, but if we allow implementations to adjust the serviceArea in general, it willl be difficult to specify how much they can adjust it.

I think it will be more pragmatic to return exactly the requested area, even if internally the implementations may perform those necessary adjustments, as long as the perceived service is not noticeably affected.

It is fine with me to return exactly the requested area.

CQM Meeting Feb 6th: Proposal to return same data agreed in meeting; @jlurien will adapt API spec as well

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.

@jlurien, according to the updated status diagram, I would like to propose the spec will say:

If the operator determines synchronously that the booking request cannot be fulfilled, the response will be 201 with status = TERMINATED or be 4xx without creating an associated booking resource.

As we discussed here, It will be good that we can have options for response in that case.

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.

We can update the diagram

@Masa8106 would you take it?

@jlurien, please let me present you an updated diagram.
Changing points are the following:

The status for a booking declined during creation is specified as "Terminated". In my opinion, it is ok for me not to create resourse for declined booking instead of "Terminated", depending on implementation.

The status "Available" and "Unavailable" are updated to "Activated (Avaiable)" and "Activated (Unavaiable)". What I am thinking is to distinguish status for booking with status for connectivity. For example, "Activated (Avaiable)" means that the booking is activated after start time is passed and the connectivity to network is fine. Though we can specify two status parameter in yaml file, so far I would like to express them in one existing status parameter.

@jlurien, @hdamker
Based on our discussion in the last meeting, I have updated the status diagram.
We can discuss on options "separate states of booking and QoS Session (Connectivity) (more complex?) vs combined state".
Let's discuss on it first in breakout session today.

I opened Issue #83 for diagram discussion.
Let's keep discussion there from now and onwards.

code/Test_definitions/qos-booking-createBooking.feature

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

Masa8106 mentioned this pull request Feb 27, 2026

QoS B: Update the status diagram #83

Open

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

3 participants

github-actions bot commented Oct 28, 2025 •

edited

Loading

jlurien Nov 13, 2025 •

edited

Loading

jlurien Nov 13, 2025 •

edited

Loading