Add method to generate system definition report

[csjall]

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

Add a VeriStand test utility to generate a string report of the system definition.

Why should this Pull Request be merged?

This change is necessary for more complete error reporting. The goal is to prefix the system definition report to all test results.

What testing has been done?

Added a new unit test for GenerateSystemDefinitionReport. All tests are green.

[csjall]

The format for the system definition report includes basic target and chassis information. Additional custom devices are also listed. Here is an example from the test.

Target: Windows Target
IP Address: localhost
Operating System: Windows
Target Control Loop Rate: 100.000000
Chassis: Chassis
Devices:
Custom Devices:
-------------------------------
Target: RT Target
IP Address: 10.2.104.35
Operating System: PharLap
Target Control Loop Rate: 10000.000000
Chassis: IO Chassis
Devices:
 - PXI1Slot7 (PXIe-6341)
 - 10MHz PLL
Custom Devices:
 - SLSC
 - Embedded Data Logger
-------------------------------

[rtzoeller]

FYI @adchurch

[rtzoeller]

Minor nitpick: the UI for the target rate exposes an integer; we probably want to reflect that instead of showing six places past the decimal.

[rtzoeller]

I'd like to see the path of the system definition file exposed somehow; I'm fine with it just being the overridden system definition instead of the original (although they may be the same in the case of no overrides), but you could optionally show both. I think this would help with tracking down test failures, since the first thing I want to do is deploy the system definition by hand and see how and where it fails.

[tannerblair]

Reflecting on this... what's the use case for this string? Is it tracability?

Does it offer any unique insight that the system definition itself doesn't?

Should we include information like channel count, models, mappings, etc.?

If that's not included here, how would I trace a test back to the system definition used to test it?

[csjall]

Reflecting on this... what's the use case for this string? Is it tracability?

Does it offer any unique insight that the system definition itself doesn't?

Should we include information like channel count, models, mappings, etc.?

If that's not included here, how would I trace a test back to the system definition used to test it?

The goal is to offer more information beyond a simply pass/fail result for each test case. Both @rtzoeller and @adchurch suggested that we include the path to the system definition under test so that developers can open that if necessary. This report offers a high level summary of the system definition that we can prefix to each test result. In my prototype the console output would look something like:

test Loopback (SLSC EDS System Tests)
 ...
Target: Controller
IP Address: localhost
Operating System: Windows
Target Control Loop Rate: 100.000000
Chassis: Chassis
Devices:
Custom Devices:
 - SLSC
-------------------------------

If the path to the system definition file under test is sufficient, then we can opt not include this string with each test result, but I believe @adchurch wants to include additional information like installed software versions.

[csjall]

Updated system definition report now looks like:

System Definition: Assets\QuerySystemDefinitionTest.nivssdf
-------------------------------
Target: Windows Target
IP Address: localhost
Operating System: Windows
Target Control Loop Rate: 100
Chassis: Chassis
Devices:
Custom Devices:
-------------------------------
Target: RT Target
IP Address: 10.2.104.35
Operating System: PharLap
Target Control Loop Rate: 10000
Chassis: IO Chassis
Devices:
 - PXI1Slot7 (PXIe-6341)
 - 10MHz PLL
Custom Devices:
 - SLSC
 - Embedded Data Logger
-------------------------------

[rtzoeller]

(To clarify, the full absolute path is shown, not the relative one).