This article describes how to create a custom test driver to extend the CODESYS Test Manager with your own, specific test actions. It is assumed that the reader already knows how to create plug-in and interface components, and has basic usage experience of the Test Manager.

Basic Architecture

Just like CODESYS itsself, the CODESYS Test Manager is extensible by Automation Platform plugins. While the Test Manager core plugin provides the infrastructure for the execution of the test script, all the test actions are provided by plugins. A plugin can provide test actions by implementing the _3S.CoDeSys.TestManager.Execution.ITestRunner and _3S.CoDeSys.TestManager.Execution.ITestCaseConfigurator interfaces (and applying the [TypeGuid("...")]-Attribute). The Test Manager uses the component manager to instantiate all the test runners and configurators, and queries them for the available test actions.

During design time (editing of a test script) as well as during run time (execution of a test script), the test manager relies on the ITestRunner to provide the functionality for the test action.

The ITestRunner interface

For execution of a test action, the test manager relies on the ITestRunner (and ITestRunner2) interface which has the following members (which are partly inherited from ITestExecutorBase):

string Name { get; }

Gets the human-readable name of the type of a specific implementation. This name is used within the XML schema of test cases and test scripts in order to reference this particular type, as well as in the user interface to name the test action. In other words, this is the token identifying the test driver.

This name must be unique within a CODESYS installation. The names for the test drivers which are delivered with the CODESYS Test Manager all start with the prefix "TestManager.", while some legacy and other drivers (most of them are delivered with the CODESYS Test Manager for Automation Platforrm, and some internal ones) start with the prefix "CoDeSys.". It is recommended that you use your own prefix based on your company or product name.

string Description { get; }

Gets a human readable, more elaborate description of your test driver.

string[] Verbs { get; }

Gets the list of verbs (aka Test Actions) provided by your test manager. This should also be human-readable tokens, as they are used in the XML schema as well as displayed in the user interface.

ITestConfigurationEntryDescription[] GetConfigEntries(string stVerb)

Gets the list of configuration entry descriptions for a specific test action. This meta data is currently not used by the test manager, but may be used in future versions for features like enchanced error checking, generic configuration editors, enhanced import/export capabilities or a python script interface.

void Execute(ITestAction action, ITestCaseInputArguments inputArgs, ITestCaseOutputArguments outputArgs, IExecutionContext context)

This method is called by the Test Manager to execute a concrete test action. Note: The ITestAction instance represents the configuration data for the test action as it was read from the test script, it does not represent the actual execution logic of the test case. Do not implement this interface, just read the configuration from the instance provided by the test manager.

void Execute(ITestAction action, ITestCaseInputArguments inputArgs, ITestCaseOutputArguments outputArgs)

Legacy variant of the Execute function without the IExecutionContext argument.

The ITestCaseConfigurator Interface

For the configuration of a test, the test manager editors relies on the ITestCaseConfigurator interface, which has the following members

string Name { get; }

Gets the human-readable name of the type of a specific implementation. This name is used within the XML schema of test cases and test scripts in order to reference this particular type, as well as in the user interface to name the test action. In other words, this is the token identifying the test driver.

This corresponds to the Name property of the ITestRunnerinterface above.

string Description { get; }

Gets a human readable, more elaborate description of your test driver.

ITestCaseConfiguratorPage[] CreateConfigPages(ITestAction action);

Gets the list of test configuration pages for your test action.

Note: You can implement both the ITestCaseConfigurator and ITestRunner2 interfaces within the same class.

The ITestCaseConfiguratorPage Interface

The test case configurator pages are returned by the ITestCaseConfigurator.CreateConfigPages interface and provide the UI for the configuration of a test case.

string PageName { get; }

The title to be shown on the tab page. Return null to use the default title, usually this is a string like "Configuration".

Control Control { get; }

Gets the Windows Forms Control which implements the actual UI and is to be shown on the tab page.

Reload()

This method is called when the ITestAction passed to ITestCaseConfigurator.CreateConfigPages has changed and the editor should refresh its contents.

bool SaveAndValidate(out string stMessage, out Control failedControl)

This method is called when the editor is closed or switches to a different test action. The configuration pages should write back their configuration into the ITestAction instance. When any validation errors are found, this method should return false, and set stMessage to an explanation of what went wrong, and failedControl to the control which contains the setting which needs to be corrected.

bool CanExecuteStandardCommand(Guid commandGuid)

Returns whether the specified standard command (Cut / Copy / Paste / Undo etc...) can be executed within this configuration page. See the documentation for _3S.CoDeSys.Core.Views.IView.CanExecuteStandardCommand() for more information.

void ExecuteStandardCommand(Guid commandGuid)

Triggers execution of the specified standard command (Cut / Copy / Paste / Undo etc...). See the documentation for _3S.CoDeSys.Core.Views.IView.ExecuteStandardCommand() for more information.