• NI Alliance Partner

    Mainline Test & Integration, Inc. is proud to announce that we are... More

  • Diligent Automation

    Our experience has shown that test teams can fall into several pitfalls... More

  • From the Blog

    Check out our blog as we discuss the latest tips/tricks/trends in the... More

Sequence Call Step Type vs. Sequence Adapter

While taking the Certified TestStand Developer exam, I noticed there were a couple of questions revolving around the Sequence Adapter.  The Sequence Adapter is not commonly used due to the fact that TestStand comes with the default Sequence Call step type.  However, I wanted to use this post to introduce the use of the Sequence Adapter in lieu of the Sequence Call step type as a TestStand best practice.  To demonstrate this, the first thing I am going to do is create a new sequence in my script and name it ‘SubSequence’.  Inside ‘SubSequence’ I will simply insert a Wait statement with a duration of 5 seconds.  The figure below shows my sequence thus far.


Back in the MainSequence I will now insert a call to ‘SubSequence’.  For the first part I will use the Sequence Call step type and name it ‘SequenceCallViaStepType’.  The figure below shows my new sequence.


Now I am going to put a breakpoint at the end of the sequence and execute the script.  Observe in the figure below how the Step.Result.Status value is set to “Passed”.


In fact, if I go to the Properties of the step and view the Expressions, you will see the Status Expression is set to the following:

(Step.Result.Status == “Done” && (Step.TS.SData.ThreadOpt == 0 || Step.TS.SData.ThreadOpt == 3)) ? “Passed” : Step.Result.Status

As you can see, TestStand actually overrides the status to “Passed” if the sequence returns “Done”.  See the figure below for the screenshot of this.


Next I am going to modify my script such that I insert an Action step type but this time I am going to use the Sequence Adapter.  The figure below shows this setting.


Back in MainSequence I will have the new Action step also call ‘SubSequence’.  This time I have named the step ‘SequenceCallViaAdapter’.  See the figure below for my new sequence.  Observe how the step description also shows the second step being an Action step type.


Now, with the breakpoint in place at the end of the script, I am going to execute the sequence one last time.  Observe in the figure below how the Step.Result.Status value is now set to “Done” for the new step.


This is a big deal in terms of developing a clean looking script.  You see, the only other step types that return a status of “Passed” besides the Sequence Call step type are the Test step types.  Now with the introduction of the Sequence Adapter, you can develop a script in which the only step types that return a “Passed” status are the Tests.  Sequence Calls are functions and should rarely be used to determine Pass/Fail criteria.  A good function should return the necessary data to a Test step type to determine a pass or failure but the Sequence Call itself should not decide.  A good function should also be developed with the purpose of being used more than once and therefore separation amongst the function and the Test is better for code reuse.

Lets look at the final report of my script in the figure below.


Imagine if this report were full of Test step types.  A quick glance at the report would make it hard for the end user to know which steps were Tests and which were Sequence Calls.  One should be able to look at the final report and know which steps are the true Pass/Fail criteria.  Especially if the Pass/Fail criteria are being traced to requirements.  In conclusion, the Sequence Adapter is a powerful alternative to the Sequence Call step type and is something that should be adopted in your scripting best practices.  It is understandable why the folks at NI would want those seeking certification to be tested on it.

No Comments Yet.

Leave a Reply

Prove your non-robot existence by filling in the blank: