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.

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();

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 )

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 Team System 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 )

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.

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.