Tests Generation Designer A Designer for Generating Complex Equipment Tests User Guide Version: 1.00
Table of contents 1. Quick Start Compiling a New Test 3 2. TGD Main components 6 a. Assemblies Explorer 6 b. Properties Window 6 c. Options Window 7 d. Grid Output Window 9 3. Properties of Components 10 a. Test Properties 10 b. Step Properties 10 c. Test-Case Properties 10 4. Miscellaneous 11 a. Saving and loading tests 11 b. DLLs and the Assemblies Path Property 11 2
1. Getting Started: Compiling a new test-case Open a new test window in one of the following ways: 1. In the menu: File New 2. Click the New Test button on the toolbar. 3. Press Ctrl+N. A new test window will appear. Note that several tests can be opened simultaneously by the editor. Additionally, the test properties are displayed in the Properties Window. If this window is not visible, open it in one of the following ways: 1. In the menu: View Properties Window 2. Click the Properties Window button on the toolbar. 3. Press Ctrl+Shift+P. Whenever you need to edit test properties, simply click on the document (every spot is all right except for the step group-boxes). Clicking on a step selects it. It also causes the step properties to be displayed in the Property Grid. 3
Load one or more assemblies that contain test cases using the Assemblies Explorer window. If this window is not visible, open it in one of the following ways: 1. In the menu: View Assemblies Explorer 2. Click the Assemblies Explorer button on the toolbar. 3. Press Ctrl+Shift+A. Select the required test and click Open A list of warnings might appear during the loading of the selected test. The warnings are meant to provide information regarding classes in the assembly that appear to be test-cases (implement ITestCase<T>) but do not meet all of the requirements. These classes won t appear in the test-case list. See Appendix A in the Developers guide for more information. If the Grid Output window is not 4
visible, you can display it in one of the following ways: 1. In the menu: View Grid Output. 2. Click the Grid Output button on the toolbar. 3. Press Ctrl+Shift+O. If the assembly contains testcases that can be use as building blocks, the test-cases will appear in the Assemblies Explorer. Drag and drop the test-cases to the steps in the document as needed. Additionally, it is possible to right click on a test case and select "Add Single" which will add a single instance of the testcase to the step, or "Add Multiple" which will prompt you to provide a number and afterwards add this number of instances to the selected step. After adding a test-case, you can edit its parameters and properties. Select the test-case you want to edit by clicking on it. 5
Change the parameter and settings as needed. You might need to expand the parameters by clicking on the + to edit complex types. Generate the test in one of the following ways: 1. In the menu: Build Generate Test. 2. Click the Generate Test button on the toolbar. 3. Press F5. Note: if you wish to override the type of the generated assembly, you can use Generate as TestCase or Generate as Fixture from the Build menu. You can now load this test-case in NUnit (if this is a fixture), or use it as a test-case (if this is a test-case). Various shortcuts to speed-up this process are present in the Tools menu. Note: when loading the test in Nunit, the following files must be present in the same directory as the new generated assembly: 1. KLATencor.TestAuto mation.emissary.dll 2. nunit.framework.dll 6
2. TGD Main components A. THE ASSEMBLIES EXPLORER Main objective Provide a way to load assemblies that contain needed test cases. Open an assembly, and load the contained test-cases to the explorer. Clear all assemblies. Switches from a list view to a tree view. B. THE PROPERTIES WINDOW Main objective Edit test, step and test-case properties and parameters. Toggle properties display: categorized or alphabetical. Property Name Property Value Property Description 7
C. THE OPTIONS WINDOW Main objective Edit various application settings. c.1: General Options The output directory of generated tests. Path to NUnit s executable. This property is not required for successfully generating new tests The default name of a generated assembly. c.2: Test Building options Number of initial steps in a new test. The background color that will be used to highlight selected steps. A flag indicating whether to request user confirmation before performing step deletion. A flag indicating whether a copy of the generated source should be saved to: <program dir>\generatedcode The default output level of new tests (when executed in NUnit) 8
c.3: Assemblies options A flag indicating whether the following extra paths should be added automatically to the referenced assemblies of new tests. D. THE GRID OUTPUT WINDOW Main objective Display various notifications to the user. Filtering support; Select the filter and click on filter. Messages of various types: Info, Error, Success and Warning. 9
3. Properties of Components A. TEST PROPERTIES Each test (window) has the following properties which can be updated using the Properties Window (by clicking anywhere in the test document): Compilation 1. Assembly name The name of the compiled assembly. 2. Manual class name Use this property if you wish to set a specific class name for your test. If this field is left empty an automatic class name will be provided. 3. Type defines the test-type. This field has the following options: a. Fixture the test will be compiled as a test-fixture, and the user will be able to load it to NUnit. b. TestCase the test will be compiled as a test-case and future tests will be able to use it as a build block. c. Both (Default value) the test will be compiled as both Fixture and TestCase. Execution 1. Assemblies Path extra paths that might contain assemblies that are needed while executing the created test. See the DLLs and the Assemblies Path property. 2. Output message controls the amount of messages that will be sent to the console while executing. From Debug level (Lots of messages) to None. The default level can be changed in the Options. 3. Referenced Assemblies a read-only property that can be used to see which assemblies are referenced directly by a given test and why (i.e. what test cases from the assembly are currently used in this test). MetaData 1. Author - test author. 2. Date time the last time that the test was modified. 3. Description test description. 4. Name test name. 5. XML Path this path will be used when Ctrl+S is pressed (save). B. STEP PROPERTIES Each step has the following properties which can be updated using the Properties Window (by clicking anywhere in the groupbox): 1. Override test-case settings a flag indicating whether the delay for the 2 nd, 3 rd test-cases should be taken from the step properties. If this value is set to true then the delay properties of the test-cases in the current step will be overridden with the step's starting delay value. 1. Starting delay the number of milliseconds that the i+1 test-case should wait before executing, after the i th test-case started its execution. This value has no affect on the first test case in the step. C. TEST-CASE PROPERTIES 2. Start delay the number of milliseconds that the test-case should wait before executing after the previous test-case started its execution. This value has no affect on the first test case in the step. 3. Parameters the parameters of the test-case. Use this property to edit the testcase parameter (this field changes according to the selected test-case). 10
4. Miscellaneous A. SAVING AND LOADING TESTS Saving a test: Click on File Menu Save/Save As, or press Ctrl+S. Loading a test: Click on File Menu Open, or press Ctrl+O. B. DLLS AND THE ASSEMBLIES PATH PROPERTY The problem Suppose that an assembly of a test named Test.dll references an assembly named RefA.dll which is located in c:\dlls. Suppose that RefA.dll references an assembly named RefB.dll which is located in c:\dlls\subdir. While executing Test.dll, the.net framework will try to locate and load RefA.dll. Loading RefA.dll will also cause the framework to try loading RefB.dll. The.Net framework does not know that RefB.dll is located in c:\dlls\subdir, so the load fails and an exception is raised. The solution Before executing the test, a list of directories that might contain assemblies is generated. This list contains: 1. Every directory that contains a directly referenced assembly. (IE. if the test references c:\dlls\ref.dll, then c:\dlls is added to the list). 2. Every directory from the Assembly Path Property. 11