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

Produce a single "tests were skipped" for multiple collections not having a timeStamp property #143

Closed
jerstlouis opened this issue Mar 2, 2021 · 4 comments · Fixed by #217
Assignees
Labels
enhancement New feature or request
Projects
Milestone

Comments

@jerstlouis
Copy link
Member

Test the presence of a timeStamp property on all collections that do have it, but report only once that tests were skipped on the n collections that don't have it, so that you don't end up with 960 "test skipped" if you test 1000 collections and only 40 have a timeStamp.

@dstenger
Copy link
Contributor

We discussed this issue in the team and came to the conclusion that it is easier to understand the test results when the skipped tests are present.
Reporting the skipped tests only once will not work because each collection is handled individually. Also, details might get lost if reporting just occurs once.
The only improvement might be to skip the execution of the tests if no timestamp is available (they will not appear in the report anymore) but, as said before, we consider the current solution as more informative for users.

@jerstlouis
Copy link
Member Author

jerstlouis commented Nov 9, 2021

@dstenger at the moment, testing 3 collections produces 27 skipped tests about missing time stamp, 9 for each collections with identical messages (org.testng.SkipException: Property timeStamp is not set in collection items {collectionId}).

Out of these 9:

  • 2 for validate Features With Limit Response Time Stamp
  • 6 for validate Features With Bounding Box Response Time Stamp
  • 1 for validate Features Response Time Stamp

That seems quite excessive -- a single message for each collection would provide the same informative value.

@jerstlouis
Copy link
Member Author

@dstenger I realized today that I was quite confused about this timeStamp warning. The Abstract Test 24 / Requirement 29 is actually not about the GeoJSON "properties" containing one called timeStamp at all, and completely unrelated to the temporal extent or datetime filtering capabilities, but it is the timestamp of when the response was generated by the server.

With that in mind:

  • it makes even less sense to generate this warning so many times (the server either decides to return a timestamp response or not, and that aplies to all requests),
  • it would be good to clarify the warning to avoid this kind of confusion:

Property timeStamp is not set in collection items 'NaturalEarth:cultural:ne_10m_admin_0_antarctic_claims'

could instead read something like:

No server response timeStamp set for collection items request ('NaturalEarth:cultural:ne_10m_admin_0_antarctic_claims')

@dstenger dstenger added the enhancement New feature or request label May 4, 2023
@dstenger dstenger moved this from Needs discussion to In progress in CITE May 4, 2023
@dstenger dstenger assigned bpross-52n and unassigned dstenger and ghobona May 4, 2023
@bpross-52n
Copy link
Contributor

@dstenger at the moment, testing 3 collections produces 27 skipped tests about missing time stamp, 9 for each collections with identical messages (org.testng.SkipException: Property timeStamp is not set in collection items {collectionId}).

Out of these 9:

  • 2 for validate Features With Limit Response Time Stamp
  • 6 for validate Features With Bounding Box Response Time Stamp
  • 1 for validate Features Response Time Stamp

That seems quite excessive -- a single message for each collection would provide the same informative value.

@jerstlouis I checked why there are so many tests executed. For example, the validate Features With Bounding Box Response Time Stamp test is executed six times for each collection (see here). We will enhance the text of the skip exceptions with information about the requested bounding box.

@bpross-52n bpross-52n mentioned this issue Jun 14, 2023
@dstenger dstenger moved this from In progress to To verify in CITE Jun 15, 2023
@dstenger dstenger assigned dstenger and unassigned bpross-52n Jun 15, 2023
@dstenger dstenger added this to the 1.5 milestone Jul 19, 2023
CITE automation moved this from To verify to Done Jul 19, 2023
dstenger added a commit that referenced this issue Jul 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
CITE
  
Done
Development

Successfully merging a pull request may close this issue.

5 participants