How to: Implement a Basic Test Type

To implement a basic test type, you must work with particular extensibility areas, as described in the following steps:

  1. Implement the core classes that define the test type

  2. Add the test type to the Add New Item dialog box

  3. Register the test type

Implement Core Classes

Write the following core classes that define the behavior of the new test type, and obtain a GUID that identifies the test type. It is recommended that you implement them in the order shown here:

  1. ITestAdapter Interface

  2. TestElement Class

  3. TestType Class

  4. TestResult Class

ITestAdapter Interface

The ITestAdapter interface tells the system how to run tests and whether a test passes or fails.

To implement the ITestAdapter interface

  • Implement ITestAdapter.Run(), which takes a test that is represented by a TestElement object. The implementation performs the test’s logic based on the properties of the TestElement object; it should also determine whether the test passes or fails and record the test results.

    public void Run(ITestElement testElement, ITestContext testContext)

    This runs a test item when the test and its associated context is provided. The test context is used to store test results and provide access to test settings.

TestElement Class

TestElement contains all the properties that represent the in-memory description of each test.

Note

Because test execution can occur in another process or on another computer, TestElement cannot rely on any Visual Studio components and must be serializable. For more information about optional properties that might be useful when you implement TestElement, see Using Optional TestElement Properties.

To implement the TestElement class

  • Create a subclass of the TestElement class. In your subclass, you must override several properties to describe the characteristics of the test that are common to all test types. You can also add more test properties to describe characteristics specific to your test type. Use code similar to the following example:

    public TestElement()

    The following code is needed for serialization:

    public object Clone();

    The following line returns the associated test type identifier:

    public TestType TestType { get; }

    Determine whether a test can be modified, after it has been created:

    public bool ReadOnly { get; set; }

    Determine whether a test can be run as part of another test, for example, as part of an ordered test:

    public bool CanBeAggregated();

TestType Class

To implement the TestType class

  • Create a shared instance of the class TestType. This class takes a GUID that uniquely and permanently identifies the test type. This instance must be returned by several different components.

    The following declaration takes a unique GUID, which you can obtain by using UUIDGEN. This TestType instance should be returned by various Test Type components.

    public TestType( System.GUID id )

TestResult Class

TestResult describes all the result data that is returned when a test runs. This class includes basic information such as whether a test passed or failed.

Note

Because TestResult objects can be passed to different processes and other computers, they cannot rely on any Visual Studio components and must be serializable.

To implement the TestResult class

  • If you want your test to report additional result data, create a subclass of the TestResult class. In your subclass, include additional properties for storing that additional data:

    public TestResult()

    The following code is needed for serialization:

    public object Clone();

    Note

    ITip tells Microsoft Visual Studio 2010 how to save TestElements to disk and load TestElements from disk. Because you define the way test items are loaded and saved, you are free to specify any file format you want, as long as the contents of the test file describe each test sufficiently. You can decide how many tests each test file will contain. A test file can contain one or more tests.

    The following returns the associated test type identifier:

    public TestType { get; }

    The following line loads a collection of test items from the specified file location. The newly created test items should keep a reference to projectData, and the warningHandler should be used to output warnings to the UI if loading fails.

    ICollection Load( string Location, ProjectData projectData, IWarningHandler warningHandler )

    Save an array of test elements to the specified file location:

    void Save( ITestElement[] rgTests, string Location, ProjectData projectData )

Add the Test Type to the Add New Item Dialog Box

To add the test type to the add new item dialog box

  • You add the test type to the Add New Item dialog box by using VSIP methods. By using these standard extensibility points, you can add a default test file, or you can add a wizard that gathers the properties of your test.

    Note

    It is recommended that you use the method of implementing file templates in which templates are defined in XML. If you use this new format and you want to make sure that your test item template, your wizard, or both appear in the dialog box for adding new tests, you must set the TemplateGroupID attribute in the TemplateData XML data set to <TemplateGroupID>TestProject-V1</TemplateGroupID>.

    To help your customers understand what your test type does, you should also describe the test type in the <Description>$YOUR_DESCRIPTION</Description> field. This description appears in the integrated information pane when your test type is selected.

Register the Test Type

To register the test type

  • In this final step, you move the generated DLLs to the correct location, register the Test Type. For more information, see How to: Register a New Test Type.

    After you complete these registration steps, your test type should be available.

See Also

Reference

TestElement

TestType

TestResult

Concepts

Using Optional TestElement Properties

Other Resources

Implementing Custom Test Types