Bug in If Verdict?

1

Attached is a simple test step that uses the itteration from a repeat step to determine if a sequence should be run. It’s intended to allow disabling a test head in a multi-DUT tester. Placing a If Verdict after this step always detects the verdict as NotSet even though the Step shows the verdict as pass or inconclusive. Am I doing something wrong or is this a bug?

//Copyright 2012-2019 Keysight Technologies
//
//Licensed under the Apache License, Version 2.0 (the “License”);
//you may not use this file except in compliance with the License.
//You may obtain a copy of the License at
//
//http://www.apache.org/licenses/LICENSE-2.0
//
//Unless required by applicable law or agreed to in writing, software
//distributed under the License is distributed on an “AS IS” BASIS,
//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//See the License for the specific language governing permissions and
//limitations under the License.
using System;
using System.Collections.Generic;
using System.Xml.Serialization;
using System.Threading;
using OpenTap.Plugins.Interfaces.Rugby_GW;
using OpenTap.Plugins.IndiePlugins.InstClass;
using OpenTap;

namespace OpenTap.Plugins.IndiePlugins
{
[Display(“Is Dut Enabled”, Groups: new { “Indie”, “Plugin Development”, “LIN”, “TestStep” }, Description: “A TestStep that Sequences DUTS”)]
public class IsDutEnabled : TestStep
{
[Display(“enDUT1”, Group: “DutControl”, Order: 1)]
public bool enDUT1 { get; set; }
[Display(“enDUT2”, Group: “DutControl”, Order: 2)]
public bool enDUT2 { get; set; }
[Display(“enDUT3”, Group: “DutControl”, Order: 3)]
public bool enDUT3 { get; set; }
[Display(“enDUT4”, Group: “DutControl”, Order: 4)]
public bool enDUT4 { get; set; }
[Display(“enDUT5”, Group: “DutControl”, Order: 5)]
public bool enDUT5 { get; set; }
[Display(“enDUT6”, Group: “DutControl”, Order: 6)]
public bool enDUT6 { get; set; }

    [Display("myDUT", Group: "DutControl", Order: 9)]
    public Input<string> myDut { get; set; }

    // Output values can be used as inputs to other test steps (see HandleInputs.cs).
    // These are useful when test step depend on output from other steps.
    [Output]
    [Display("DUT", Group: "DutControl", Order: 8)] 
    public int CurrentDut { get; private set; }

    public Verdict myVerdict { get; set; }

    public IsDutEnabled()
    {
        enDUT1 = true;
        enDUT2 = true;
        enDUT3 = true;
        enDUT4 = true;
        enDUT5 = true;
        enDUT6 = true;
        CurrentDut =1;
        myDut = new Input <string>();

// MyVerdict = Verdict.NotSet;
}
public override void Run()
{
myVerdict = Verdict.Inconclusive;
CurrentDut = Convert.ToByte(myDut.Value.Split(’ ')[0]);
switch (CurrentDut)
{
case 0:
break;
case 1:
if (enDUT1)
{
myVerdict = Verdict.Pass;
}
break;
case 2:
if (enDUT2)
{
myVerdict = Verdict.Pass;
}
break;
case 3:
if (enDUT3)
{
myVerdict = Verdict.Pass;
}
break;
case 4:
if (enDUT4)
{
myVerdict = Verdict.Pass;
}
break;
case 5:
if (enDUT5)
{
myVerdict = Verdict.Pass;
}
break;
case 6:
if (enDUT6)
{
myVerdict = Verdict.Pass;
}
break;
}
}
}
}

1 Like
2

Hello @craig.petku,

Could you provide more information on your implementation? What version of TAP are you using? Also could you include the test plan you are trying to run?

I have attached an example test plan that implements a basic branching (BranchExample.TapPlan). There is a Dialog step which asks the user to press OK or Cancel to set the verdict to Pass or Fail accordingly. The verdict of that step is used in the next two If branches, depending on which button was clicked on the dialog then one of the two branches will be executed.

BranchExample.TapPlan (2.8 KB)

Here is an example of the test plan run selecting Ok on the Dialog, the first branch is executed:

image
image1536×1173 140 KB

Here is an example when click Cancel on the Dialog:

image
image975×745 254 KB

Thank you,

Carlos Montes

3

I finally had time to work on this and it was my mistake. While learning to write plugin-s I had assumed the verdict needed to be declared and had added a local verdict to the test step. The code was updating thisa verdict and not the one shared with other test steps. The strange thing was the test step always showed a n updated verdict, but the steps accessing the verdict read different results.

4

I am glad you found the mistake. The TestStep base class already defines a Verdict which is updated when you call UpgradeVerdict, you can define your own Verdict and then make sure to call UpgradeVerdict with your own defined one:

Verdict MyVerdict = Verdict.NotSet;

// Perform limit check.
var result = 2.5;
if (result > LowerLimit && result < UpperLimit)
{
MyVerdict = Verdict.Pass;
}
else
{
MyVerdict = Verdict.Fail;
}
UpgradeVerdict(MyVerdict);