-
Notifications
You must be signed in to change notification settings - Fork 221
Description
As the number and scope of PURL test cases grows we need a way to define a unique identifier for each test case.
A common use case is to how to easily communicate a set of failing test cases for a PURL implementation tool. The failing test cases might be in a single test file or across multiple test files. There is currently no unique test case identifier within a test file.
Based on schemas/purl-test.schema-0.1.json each test case must have a description but there is no requirement that a description is unique within a test file. In some cases the description is unique within a test file, but in many cases it is not unique and there is no current requirement or method to enforce uniqueness. It seems unnecessarily complex to define uniqueness from a combination of test case fields.
Two potential approaches to enforce test case uniqueness within a test file are:
- Use description and require it to be unique within a test file. This could be enforced with a CI workflow to check for uniqueness for any new or changed test file. This approach should not require a change to the PURL test schema because the PURL test schema only defines test cases; it does not define how to aggregate test cases into files.
- Add a test_case_id field which could be an "arbitrary" number or other string. The new field could be generated or assigned by the test file maintainer and its uniqueness could be enforced with a CI workflow to check for uniqueness for any new or changed test file. This approach would require a change to the PURL test schema to add the new field.
This issue overlaps with:
- Move test cases from collections to atomic test files #765 because the test file path will serve as a unique test case identifier if we adopt the "atomic" test file approach.
rewritten Feb 5, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
Status