PAE-463: Added schema validation to test the epr-organisation seed data

[tomhalley]

Ticket: PAE-462
Ticket: PAE-463

This pull request updates several organisation fixture files and the organisation schema validation logic. The main focus is to improve the consistency and completeness of test data, particularly around registration and accreditation details, and to refine schema validation for nullable fields.

Fixture data improvements:

• Added explicit registrationNumber, accreditationNumber, validFrom, and validTo fields (with appropriate values or null) to all registrations and accreditations in sample-organisation-1.json, sample-organisation-3.json, and sample-organisation-4.json for better data consistency and downstream test reliability. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

• For sample-organisation-2.json, populated registration and accreditation fields with realistic values, added new file upload fields, updated approved persons, and corrected orgId formatting for consistency with other fixtures. [1] [2] [3] [4] [5] [6] [7]

Schema validation logic:

• Updated the organisation schema in schema.js to allow fields to be explicitly set to null when not required, improving flexibility for optional fields in test and production data.

General fixture corrections:

• Fixed orgId formatting in sample-organisation-2.json and sample-organisation-4.json to use six digits for consistency. [1] [2]

Accreditation and registration completeness:

• Ensured all accreditations and registrations in the fixture files have the expected fields, supporting more robust validation and test scenarios. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[nijk]

Nice work

[senthilinfy]

can you use the utilities in validation.js to validate the seed data jsons? might be better to create a file named seed-data.test.js as schema validation tests are there in validation.test.js and contract tests.

Also validation.js is meant to be abstraction over the shema.js. The schema.test.js is accessing schema directly

[senthilinfy]

also consider inserting seed data through repository. that should fail validation

[nijk]

I hadn't realised we were still using the old way to importing the seed data. It feels like this is the thing to fix