MSDN Magazine Launch Issue - February 15, 2008 - (Page 30) click OK. VSTE for Testers has built-in templates for load tests, unit tests, and Web tests. The Generic Test type is essentially a wrapper for custom test automation and has all the plumbing necessary to enable custom automation to interoperate with VSTE for Testers. The screenshot in Figure 4 shows you what the process of wrapping custom test automation as a Generic Test looks like. The first field specifies an existing test program to run. This value must be the path to an .exe file. (While I used an absolute path in this example, you can additionally specify the script path as an environment variable, a relative path, or a deployment path.) In the case of script-based test automation, this is the cscript.exe program, usually located at C:\Windows\System32\. If your test automation is an .exe itself, such as a C# program, you would specify the full path to your automation. The second field specifies commandline arguments that are to be passed to the .exe file specified in the first field. In this example, the value would be the full path to the script, such as C:\VSTTIntegration\Scripts\testSimple.js. These are the only two fields you need to specify in order to run simple script-based tests with internal test case storage. There are several ways to run tests from within VSTE for Testers. One simple way is to display all tests in your project by clicking on Test | Windows | Test View. Then select the test you wish to run, right-click on the test name, and click Run Selection. The screenshot in Figure 5 shows an example. The Test Results window displays the overall pass/fail result. If you double-click on the result, you get detailed results including the test run duration, start time, end time, and a copy of the console output. A test result is stored by default on the host machine as an XML file with a .trx (test results XML) file extension in a TestResults subdirectory. By default, these .trx file names are stamped with user name / machine name / date / time, making them easy to organize. The actual structure of .trx files is somewhat complex but easy to interpret. For example, a small part of the .trx file generated by this example Generic Test is: The test failed with exit code 1. The example I’ve just described wraps custom test automation that has test case data embedded into the automation code. If your automation reads test case data from an external source, you may need to edit one of the Generic Test fields. Suppose your test automation resembles this: var fsi = new ActiveXObject( “Scripting.FileSystemObject”); var fi = fsi.OpenTextFile(“.\\testCases.txt”); while (!fi.AtEndOfStream) { line = fi.ReadLine(); // parse test case data // call method under test // determine pass/fail } Figure 4 Creating a Simple Generic Test Figure 5 Executing a Generic Test Here the script uses a relative file path to read test case data from a file located in the same directory as the script. When a Generic Test executes, it copies the executables into a working directory, which means the test case data would not be found. One solution to this is to specify a hardcoded path in the Working Directory field when you create a Generic Test. A slightly more flexible approach is to set the values of one or more environment variables such as %TestDir%, %TestLocation%, and %TestOutputDirectory%, and then use these environment variables to control your test execution. However, the most flexible option is to declare the script as a deployment item in Visual Studio. By doing this, your test case 30 msdnmagazine Test Run
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.