ZGW API postman test issues / requests

[aurimasroxit97]

I have a couple of requests / concerns regarding ZGW Postman tests:

1. In ZGW API tests 012-d, 012-e, 012-f, errors are tested not in alphabetical order - for example, verlenging.duur should come before verlenging.reden

2. It would be useful to be able to configure JWT token with env. variables (setting properties like iss, aud and others from variables). Also, expiration date ("exp") should be added. This would make it easier for tests to be integrated with build / release pipelines out of the box.

3. When tests for ZGW version 1.1 become available, will they be mixed up with version 1.0.x tests? If so, would it be possible to keep tests for different versions separated?

Please let me know your opinion on these questions / requests. Thanks

[michielverhoef]

1. In ZGW API tests 012-d, 012-e, 012-f, errors are tested not in alphabetical order - for example, verlenging.duur should come before verlenging.reden

The reason verlenging.reden is tested before verlenging.duur is because in the OAS verlenging.reden is defined before verlenging.duur. See also JSON Schema at https://zaken-api.vng.cloud/api/v1/schema/#operation/zaak_read

2. It would be useful to be able to configure JWT token with env. variables (setting properties like iss, aud and others from variables). Also, expiration date ("exp") should be added. This would make it easier for tests to be integrated with build / release pipelines out of the box.

This feature request will be passed on to the team that will work on the development of the Autorisaties API .

3.When tests for ZGW version 1.1 become available, will they be mixed up with version 1.0.x tests? If so, would it be possible to keep tests for different versions separated?

The tests for 1.1 should be available as they were part of the release of 1.1. These tests will replace the 1.0 tests. As the 1.1 versions is supposed to be backwards compatible with 1.0 I would expect any 1.0 implementation to be compatible with the 1.1 tests. If this is not the case, please let me know.

[aurimasroxit97]

Thank you for your answers. It is now clear (question one) why 012-d, 012-e, 012-f are validated in such a way.

Regarding question three, we haven't started implementing V1.1. But, if this version is supposed to be 100% backwards compatible, then there is no reason to have those tests separated, as I thought there will be at least some incompatibilities.

Regarding question no. 2, construction of JWT token does not have anything to do with Autorisaties API. JWT token for postman tests is created in collection pre - request scripts. (In Postman, go to Edit collection -> pre request scripts) Currently, scripts take "client_id" from an environment variable for the JWT token. We expect this to happen for all other claims, like "iss", "aud" and so on. Also as mentioned before, adding additional claims like "exp" should be possible through env. variables as well. Please let me know if this makes it more understandable.

Also, one more question: we internally discussed test case zrc-014d. Even though this test only sets betalingsindicatie in pre - request scripts, it still also sends laatsteBetaaldatum, because it was set on test zrc-001a. Can you comment if this test is meant to send laatsteBetaaldatum in its body or was this an oversight? Thank you.

[johannesbattjes]

@michielverhoef I am concerned about the 1.0 test. We use this test to test if we are compliant (using all 800+ test steps), If this test project is replaced we cannot show anymore that we are compliant (because many 1.1 test steps will fail). Why not keeping the 1.0-test apart? So that we can still prove 1.0 compliancy.