To get started with the System Coverage feature of LegiTest, open a LegiTest suite in Visual Studio. Once open, we need to go to the Server Integration node. Here, enter in the address of the server that contains the installation of Workbench Server. This will give access to the Doc xPress metabase, which is what our report will be built from.
Once a server has been setup. We can then visit the System Coverage node. Here we will select a test, in this example we have a SQL Comparison, comparing two tables within the same database. The database being tested is called GridStuff, and the two tables are Grid1 and Grid2.
In the Doc xPress search section, we typed in GridStuff, as we want to specify that this specific test is responsible for representing the "health" of the GridStuff object. To do this, we will highlight GridStuff, and click the "Add" button to add it to this test.
Once you have the items you want represented by this test, we will save the project. Be sure that on the server integration page that "Push results..." is checked. Once saved, we will run the test and then visit the server to create a report that includes this item.
To access the System Coverage on the server, first visit the LegiTest Server dashboard. From there, you will see System Coverage in the navigation bar.
Clicking on System Coverage will bring you to the Reports dashboard. Here, if there any reports available, you will be able to see a list of them, and select the report you wish to view. For now, lets click the "Create Report" button to begin creating our first report.
ON the create report page, we will need to provide a name for the report. Once provided, use the search bar to search the Doc xPress metabase for items we can add to the report. For the demo, GridStuff was added, since we know that the GridStuff item was added to a test. This now becomes a report item in the report. When an item is added, the reporting for that item starts at the Path level for it, and then calculcates downward. We will see how that works after our report is created. Fore this example I will also add the \Databases path as a report item as well. Once all items you desire to be in the report are added, we can then create the report.
Once the report is created, we are taken to the report page. On this page, the top report item will be the total of all items added to the report not pictured). The second graph shown is for the GridStuff item we added. We can see that since the test failed that represented the GridStuff item, the entirety of it's path is considered failed. The second report item, Databases, shows a percentage of failurs, passes, and not tested items. In tests that were not show in the setup, there were some tests that tested the health of AdventureWorks, those tests passed, therefore we see some passes for items under the Databases path, and failures, which represent the GridStuff test added for this example.
These graphs are a quick way to view the status of your environment. In order to a get a more detailed view though, in the top right of the report, we can click "Tree View" to switch to a drillable view. Here we can drill into a path to see where these failures and passes occured.
During report creation, you can choose which view to default to. By checking the "Default to Tree View" option above the "Create Button", the report will be opened to the tree view each time instead.