Table of Contents

Test Workflows

Test workflows allow test processes to be defined via standardized workflow definitions and then integrated into the unit process that occurs at Acuit Pinpoint Workstation. This greatly reduces the custom code that must be written to implement even complex testing scenarios, and makes later changes to the test process much easier. Most of the process and test parameters are defined via configuration files, greatly streamlining updating and deploying test process changes.

Test workflows leverage Acuit Pinpoint workflows to provide a framework for:

  • Authoring test workflows, with additional standard activities specific to testing units.
  • Supplying test parameters for the workflow from various configurable sources.
  • Integrating with test equipment via standard interfaces.
  • Creating custom views that provide the custom testing user interface.
  • Configuring how the test integrates with Acuit Pinpoint Workstation.
Note

Using test workflows is not required when integrating unit testing with Acuit Pinpoint. Any Acuit Pinpoint Workstation plug-in need only use IWorkstationService.AddTestResult2 (or IWorkstationService.AddTestResult) to submit test results, providing its own custom user interface and logic as needed. However, using test workflows is usually preferred.

Also, only portions of the test workflows framework need be used, as desired. For example, the framework can be used to cause the last test result to be displayed on the main UI, without any custom test workflow or test view to be defined.

General Steps

These are the general steps to create and use test workflows with Acuit Pinpoint Workstation:

  1. If needed for your custom test, create a new Acuit Pinpoint Workstation plug-in to contain:
  2. Author your test workflow defining the test process.
  3. Create your view defining the user interface.
  4. Package your workflow and view file(s) together into a workflow package file.
  5. Deploy the files and configure Acuit Pinpoint to use them.

Acuit Pinpoint Workstation Testing Framework

When a test type is configured for an Acuit Pinpoint Workstation station, Acuit Pinpoint Workstation does the following to host the test workflow.

Note

Multiple test types can be configured at the same time, for the same station.

Initialization

During initialization, Acuit Pinpoint Workstation will do the following for each configured test type:

  1. Load the workflow from the workflow XAML file.

  2. If the ShowTestStrip [setting] in TestType Section is true (the default), add a strip to the MannedUnitPlugInRegion region containing:

    • The test type name
    • A "New Test" button (if a test workflow is defined)
    • Information about the last test result
    • (Or, optionally, custom content defined via the TestStripViewFile setting in TestType Section

    This strip will be hidden when the test type does not apply to the unit and the HideTestStripWhenNotApplicable [setting] in TestType Section is true.

  3. If a test view exists and is not configured to use the MainRegion region, load the view from the view XAML file and place it in its configured region.

Unit Scan

The test strip described in the previous section will be enabled or disabled, depending on whether the test type applies to the scanned unit.

"New Test" Click

Note

This button will only appear when a test workflow has been defined.

When the "New Test" button in a test type strip is clicked (which is only possible when a test workflow is not already running), Acuit Pinpoint Workstation will do the following:

  1. Raise the NewTestRequested/{TestTypeName} workflow event, which will start the workflow configured for this test type.
  2. If a test view exists and is configured to use the MainRegion region, load the view from the view XAML file and navigate to it in the region.

Workflow Execution

While the workflow is executing, the test workflow and test view manage performing the test.

The test view can cancel the test workflow via the CancelWorkflowCommand or CancelWorkflowAndCloseTestViewCommand command. Canceling a work flow is useful for canceling a new test, before any actual testing has commenced. For example, there could be a "Cancel" button when the test process initially prompts the operator to make connections before initiating testing. When a workflow is canceled, all processing is stopped and no more activities will run. Cleanup activities in the workflow, such as ensuring power is off to the unit, will not occur, so canceling a workflow is not an appropriate way to abort a test in progress.

Test View Lifetime

Note that the test view lifetime is independent if each test workflow execution. In particular, the test view can be visible and interactive even when the test workflow is not running.

When the test view is configured to not use the MainRegion region, it will be always visible and active with its region—before, during, and after each test workflow run.

When the test view is configured to use the MainRegion region, it will initially be loaded and shown at the same time that the test workflow is started, but it will continue to be visible and interactive after the workflow completes or is canceled. The view must provide a way to dismiss itself, via the CloseTestViewCommand or CancelWorkflowAndCloseTestViewCommand command.

Either way, the test view can start a new test workflow run via the RestartWorkflowCommand command.

Authoring Test Workflows

Test workflows are just regular workflows that make use of some additional activity types added by the test workflows framework:

In particular, every test workflow should contain a RecordTest activity that wraps the actual execution of a test within its Body. There can be workflow activities outside of the RecordTest activity, such as steps needed to prepare for starting a test and steps needed after a test is complete, but each time the RecordTest activity is initiated, a test result of some kind will eventually be recorded for the unit (unless the activity is canceled or there is no unit at the station).

Important

Executing a test workflow is not necessarily the same as performing a unit test:

  • A test workflow could be executed that prompts the operator to prepare to start the test, but is canceled without ever starting a test, so no test result would get saved for the unit. (The test workflow ran to completion without ever executing a RecordTest activity.)
  • A test workflow could be executed that causes multiple test results to get saved for the unit before the test workflow completes. (The workflow execution caused a RecordTest activity to run multiple times—either the same one due to a loop in the workflow, or different ones defined in the same workflow—before the workflow ran to completion.)

Workflow Parameters

Acuit Pinpoint Workstation provides the following parameter value sources to the workflow:

  1. The additional parameter value sources provided with the NewTestRequested workflow event.
  2. The regular parameter value sources provided to the workflow event handler.

The various possibilities for workflow parameter value sources provides great flexibility for defining and adjusting test parameters. Whenever the test process could be affected by an adjustable parameter (e.g., a test value acceptance tolerance, a time delay duration, a fault code value, etc.), a parameter can be defined at the top of the workflow and used as appropriate by activities within the workflow. If there is a reasonable global default for the parameter, the default value should be defined with the parameter definition within the workflow.

For parameters that are expected to vary from model to model, it might be appropriate to not define a default value with the parameter definition, and instead expect that a value will be provided via a unit parameters table.

Either way, workflow parameters can then easily be tweaked at whatever context level is appropriate or convenient. For example, say there is a parameter defined for the workflow with a default value, as it was assumed the default value would work for the test and never need to be adjusted. Later, it is determined that the default parameter value needs to be adjusted. Rather than updating and deploying a new version of the workflow definition, a new value for the parameter value can simply be defined via a setting defined in the line configuration, and the workstation(s) would automatically start using the new value. Later yet, it is determined that the parameter value must be different for a few specific unit models. A column can simply be added to the unit test parameters table for that parameter name, and a value can be provided for those specific models, leaving the values for all other models blank. Again, the workstation(s) will automatically start using the new value for those models. Neither change required any changes at the workstations.

Test Equipment

If the test requires integration with any external test equipment, an Acuit Pinpoint Workstation plug-in must be created that supplies the integration with the device(s).

The plug-in should register a new device type with the IDeviceRegistry device registry service for each type of external device with which it must integrate. The plug-in can then provide custom workflow activities that reference and use registered devices.

Data Context

The workflow data context is of particular usefulness for test workflows, as it is how data from the workflow is made available to views that present the user interface for the test. Any data to be displayed in a view must be defined as a top-level variable. Views can then bind to those data items by name, via WorkflowData.

Views

The workflow definition does not contain the user interface shown to the operator on the Acuit Pinpoint Workstation display. Views are used to define the user interface using WPF XAML files. The view interacts with the test workflow via a "view model" provided to the view by Acuit Pinpoint Workstation.

These XAML view files are similar to what might be used to create a custom test user interface within a custom plug-in (i.e., as described by Walkthrough: Create an Acuit Pinpoint Workstation Plug-in). However, they are included in a test workflow package as raw XAML files; they are not compiled into a custom plug-in.

Note

While both the workflow and views are defined via XAML, they use different sets of elements.

Acuit Pinpoint Workstation automatically provides a "view model" object to the view (i.e., it sets the view's DataContext property to it) of type ITestViewModel. This allows elements in the view to be bound to properties of the view model.

Binding Examples

  • A view could contain a button that raises a UICommandEvent that can trigger a WaitForUICommand activity in a workflow like this:

    <Button Command="{Binding WorkflowUICommand}" CommandParameter="Continue">Continue Testing</Button>
    
  • A view could display elapsed time from a Stopwatch workflow activity like this:

    <TextBlock Text="{Binding WorkflowData.ElapsedTestTime, StringFormat='{}{0:h\\:mm\\:ss}'}" />
    
  • A view could collect comments from the operator into a workflow variable like this:

    <TextBox Width="500" Text="{Binding WorkflowData.OperatorComments}" />
    

Expressions

In the test workflows framework, the environment for C# expressions is expanded:

  • These additional namespaces are imported:
    • Acuit.Pinpoint.Workflows.Testing
    • Acuit.Pinpoint.Workflows.Testing.IO

To allow expressions in a test workflow to use types provided by a plug-in assembly, a reference to that assembly must be added to the expression environment. To do this, add this to the plug-in module's Initialize method:

ExpressionEnvironment.Instance.AddReference(Assembly.GetExecutingAssembly());

Services

The following services are provided by Acuit Pinpoint Workstation for use by custom activities:

Also, custom activities can interact with the active test via the following services when they are placed within the body of a RecordTest activity:

Of course, you can provide your own custom services of any type for use by your custom activities via the standard Managed Extensibility Framework (MEF) facilities used by Acuit Pinpoint Workstation. In your plug-in, use the ExportAttribute attribute to export the service that you want to make available to your activities. For example:

using Acuit.Pinpoint.Workflows;
using Acuit.Pinpoint.Workflows.Activities;
using Acuit.Pinpoint.Workflows.Extensions;
using System.ComponentModel.Composition;
using System.Threading;
using System.Threading.Tasks;

[Export]
public class MyCustomService
{
    public Task DoSomethingAsync(CancellationToken cancellationToken)
    {
        // Do something asynchronously...
    }
}

public class MyCustomActivity : Activity
{
    protected override async Task OnExecuteAsync(ActivityContext context, CancellationToken cancellationToken)
    {
        var myCustomService = context.ServiceProvider.GetRequiredService<MyCustomService>();
        await myCustomService.DoSomethingAsync(cancellationToken).ConfigureAwait(true);
    }
}

Workflow Package Files

For easier deployment, workflows and their associated views should be packaged together into a workflow package file, which is simply a zip file.

A simple workflow package will simply contain the workflow and view files named as follows and zipped into a zip archive together with no folders:

  • Workflow.xaml
  • View.xaml

Using this layout simplifies configuration, as only the workflow package file will need to be referenced by the settings. Acuit Pinpoint Workstation will automatically find the workflow and view files within the package.

If images or other view files are referenced by the workflow and/or main view file, they should be added to the zip file as well. For example:

  • Workflow.xaml
  • View.xaml
  • Logo.png
  • Prompts
    • ConnectUnit.xaml
    • ConnectUnitDiagram.jpg
    • DisconnectUnit.xaml
    • DisconnectUnitDiagram.jpg

Deploying and Configuring in Acuit Pinpoint

Test workflows are configured for Acuit Pinpoint Workstation via Testing Section. Generally, the following should be done to deploy and configure the authored test workflow for use in Acuit Pinpoint Workstation:

  • Deploy any necessary custom plug-in(s) to the server.
  • Deploy the workflow package file to the server.
  • For each Acuit Pinpoint table that will contain per-model test parameters, either create and manually upload the table via the Acuit Pinpoint web interface, or configure it via <table> Element. Be sure to include a column that will contain unit model number alias match patterns.
  • Configure the test type as appropriate via <test> Element.
  • For the station type that will perform the test, use <settings> Element to configure these settings:
    • Reference the custom plug-in(s) via PlugIns in Workstation Section.
    • Configure the settings in TestType Section:
      • Set TestTypeName to the test type name.
      • Set Workflow:WorkflowPackageFile to the path to the deployed workflow package file.
      • Add a Workflow:Parameters section containing test parameters, as needed.
      • Add Workflow:UnitParametersTables values for each Acuit Pinpoint table containing per-model test parameters.
      • Set ViewRegionName to the desired location for the test view.
Note

Test workflows can also be configured via a workflow event handler for the NewTestRequested/{TestTypeName} event, but that method does not support view files packaged within a workflow package file.

Example Configuration

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.acuit.com/pinpoint/5.0/LineConfig.xsd">
  <line>
    ...
    <tests>
      <test name="Run Test" />
    </tests>
    ...
    <stationTypes>
    ...
      <stationType name="Run Test">
        <settings>
          <setting name="Workstation">
            <setting name="PlugIns:0" value="C:\ProgramData\Acuit Pinpoint\Acuit.Pinpoint.Server\PlugIns\Custom.RunTestPlugIn.1.0.0.zip" />
            <setting name="Testing:TestTypes:0">
              <setting name="TestTypeName" value="Run Test" />
              <setting name="Workflow">
                <setting name="WorkflowPackageFile" value="C:\ProgramData\Acuit Pinpoint\Acuit.Pinpoint.Server\PlugIns\Custom.RunTestProcess.1.0.0.zip" />
                <setting name="Parameters">
                  <setting name="Parameter1" value="100" />
                </setting>
                <setting name="UnitParametersTables:0">
                  <setting name="TableName" value="RunTestParameters" />
                  <setting name="ModelNumberAliasColumnName" value="Model" />
                </setting>
              </setting>
              <setting name="ViewRegionName" value="MainRegion" />
            </setting>
          </setting>
        </settings>
      </stationType>
    </stationTypes>
  </line>
</configuration>