Bret,

Initializing variable in declaration for structures and arrays introduces use of intrinsics.  Since it is possible for unit test sources to be used for both host and target tests, I recommend we continue to follow the EDK II coding style for unit tests to support maximum compatibility and code reuse.

Using a module global variable with initializers instead of initializing a local declaration is the same amount of work, so I do not believe that will result in fewer tests.

I agree it is useful to have the test data next to the test code.  This can be accomplished by breaking up into more files so the test data is immediately above the test function the test data is used.  Does ECC raise an error if a module global is placed between 2 functions?  A 2nd approach to put the module global immediately above the test function the test data is used.

Best regards,

Mike

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret Barkelew via groups.io
Sent: Tuesday, October 6, 2020 5:28 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] VariablePolicy: Final Changes Thread 2 - ECC & UnitTest

I’ve worked through all the ECC issues with Variable Policy (AND the UnitTests) on this branch:
Commits · corthon/edk2 (github.com)<https://github.com/corthon/edk2/commits/var_policy_dev_submission_v8>

I even wrote the Main() entry point lib that Laszlo suggested (it works rather nicely):
TEMP: Staging for HostTest entry point · corthon/edk2@4ce5210 (github.com)<https://github.com/corthon/edk2/commit/4ce52108b3e1bcb2ba78995be94c3949fe647eda>

However, there’s one that I just can’t get past and I would like to take it up with the community. I don’t think that UnitTests should have to deal with the “can’t initialize variables in declaration” check. Almost none of the solutions that I tested worked, and the ones that did were too cumbersome. They failed on two key points that are important for test writing:

  *   They were annoying to write ===> fewer tests.
  *   They moved even more of the test case data away from the test ===> harder to read tests.

I would like to move for an exception for unit tests (or at least host-based unit tests), but I don’t know how to accomplish that from a technical standpoint.

Thoughts?

- Bret