This chapter explains what design- and run-time GUI objects are and how to analyze them with GuiProf.
Introduction
As was explained in chapter What is GUI Test Coverage?, GuiProf needs to know what GUI objects your program consists of. This information is essential to measure GUI test coverage. To get this information, GuiProf uses design-time analysis and run-time analysis of the application under test (AUT).
GuiProf can read information about classes in an assembly using .NET reflection. Based on this information, GuiProf displays all GUI types containing in an assembly. They are called design-time objects because they were created by the developers in the process of application design.
Opening Assemblies
To open an assembly for design-time analysis, you can:
| • | Go to File → Open... menu and select an assembly (*.dll or *.exe file) |
| • | Drag-and-drop an assembly file from the Windows Explorer |
| • | Select a referenced assembly in folder References and choose Context Menu → Open |
If an assembly does not contain any GUI objects, it is marked as GUI-less. You can remove it using Context Menu → Remove.
Analyzing Design-Time GUI Objects
GuiProf represents the GUI objects of an assembly as a tree. For each form in the assembly you can instantly see the hierarchy of child controls. You can also see the properties of GUI objects in the Properties view.
Creating Objects
If you want to have a look at the form without having to run the application, you can select Context Menu → Create Object. This menu is available only for top-level objects in an assembly. GuiProf displays the object in a separate host window.
Unfortunately, it may not always work, because GuiProf creates this form not in the context the form expects. For instance, the form expects to be a child of the main window of the AUT. Instead, it is created in the GuiProf host window. Therefore, sometimes the form cannot be created at all or looks or behaves not as intended.
Drawbacks of Design-Time Analysis
Design-time analysis is a very powerful feature. In most cases, it provides correct and complete information about existing GUI objects to measure the test coverage. However, there can be GUI objects that design-time analysis fails to find.
During design-time analysis GuiProf tries to create instances of GUI objects. This allows GuiProf to display hierarchy of child objects. Unfortunately it does not always work, because the GUI objects are created not in the same context that was intended by the application developer. In case GuiProf fails to create an instance, it displays a warning in the Properties view.
Another problem of design-time analysis is that, as suggested by its name, it shows only objects that are known at the design-time. Some objects, however, can be created dynamically at the run-time.
To learn how you can overcome these problems, read about the run-time analysis below.
GuiProf can capture all GUI objects that exist in your running application. To do that, profile the application and make a run-time snapshot. GuiProf creates a model of your running application and adds it to the folder Design-Time Objects. This model contains all GUI objects that currently exist in the application, including those that GuiProf could not detect during design-time analysis.
When to Use Run-Time Analysis
As already mentioned above, GuiProf usually detects all existing GUI objects during design-time analysis. If you see that some forms, menus, etc. are not found at all or not fully displayed, you can manually add them by making a run-time snapshot.
Another use case lies outside the domain of test coverage measurement. You can make snapshots to analyze the run-time GUI tree of the AUT. The snapshot shows you what objects your application consists of and how they related to each other.
See Also