Generic tests on config files as unit test

[fcc753]

Is your feature request related to a problem? Please describe. As discussed on 2023-03-17

When updating config files for all environments, it happens that typos are introduced in configs for an environment that will not be deployed/validated directly [like ACC,PROD or DEMO]. When time to deploy in this environment has come, the build is pushed to the machine and fails for a stupid comma... and that a new build deploy cycle has to be executed.

Describe the solution you'd like

Include in each BE project Tests a validation of config file

• details of what I am doing below.

I have put a single file generic unit test in my projects (identical for all) that validates all the appsettings.json and reverseproxy.json file [and per env variants].

• The goal is just drop in test folder with no changes and it works
• It checks that file is a correct json, and properly reports the parser errors [catches simple typos, etc]
• It checks the file can be loaded as a Config file catches errors reported by the Configuration parser [typical case: duplicate keys,...]
• By populating an extra method, can check whatever one want to ensure systematically on all the config files
• It is compatible with both older projects having foo.iishost projects or newer ones that have foo.host projects.

I put this unit test in each BE/Tests folder so that even when config is broken locally in one BE preventing it to build, the test can be run in another of the project backends and provide details on the errors.

It allows then early detection of broken config at build time since build will run the tests...

Limitations

• no attempt at coping with front end(s) configs
• no attempt at much older xml based config either...

• Describe alternatives you've considered None

Additional context I am attaching the file here and suggest this file or an improved version is added in the BE\Foo\Tests for each BE Foo of the solution generated by the guidance. ConfigfilesHaveProperSyntax.cs.TXT

[vvdb-architecture]

A lot of these issues are less critical since (at least for back-ends), the environment-specific appsettings contain only the changes for the specific environment, and are therefore much smaller and easier to check.

[fcc753]

I do not disagree on the criticality. It just remains that those stupid typos will jump in your face at deploy time in place of being caught at build time. Fail early is better IMHO.

D.

################################################################################################### This message and its attachments may contain confidential information protected by intellectual property rights or other rights & is strictly for the exclusive use of the intended recipient. It is strictly prohibited to copy, alter or disclose this message or its contents to any other person without Elia's prior consent. If you are not the intended recipient of this message, please inform the person who sent it and delete the message from your system. All messages sent to and from Elia may be monitored to ensure compliance with internal policies, to protect the company's interests and/or to remove potential malware. Elia is not liable for any direct or indirect damage arising from errors, inaccuracies or any loss in the message, from unauthorized use, disclosure, copying or alteration of it or as a result of any virus being passed on. This message does not constitute any commitment from Elia except when expressly otherwise agreed between the intended recipient and Elia. U vindt de Nederlandse versie van deze disclaimer op onze internetsite www.elia.be Vous pouvez decouvrir la version francaise de ce disclaimer sur notre site internet www.elia.be ####################################################################################################