Improving TestStand Developer Experience

Last year I was presenting at Global LabVIEW Architects Summit. However, I wasn't talking about LabVIEW but TestStand. To be more precise, about TestStand Developer Experience and its main IDE - Sequence Editor.

You can watch the recording here.

If you can ignore poor audio-video synchronization, my linguistic incorrectness, and the fact that I'm not a natural-born speaker, you could learn a couple of tips and tricks.

Below you can find the presentation overview.

In 0:30 I talk about the user/developer experience in general. In this quasi-philosophical part, I wanted to initiate a discussion about all the aspects of software development that improve the way we feel about our tasks, but with a focus on the IDE. What are the most important features that every environment should have? Do you agree with my list? What, besides the IDE, has the greatest impact on the DX?

The first part is a baseline for the discussion about TestStand DX. The rest of the presentation demonstrates selected aspects of TestStand-based development which we can improve.

In 12:00 I talk about one of the most important improvements of TestStand introduced in 2016 which is the *.tsenv file. Thanks to the custom TestStand environment we can customize the experience in a more controllable way. I show, among the others, how I overcome the "problem" of selecting appropriate environment files using scripts.

In 25:10 I show how we can customize Sequence Editor and how to assign a layout and UI settings to the user and automatically reload it to adapt to the currently logged-in user. I also suggest considering using Sequence Editor as the main GUI instead of maintaining a separate codebase of custom Operator Interfaces. The demo can be found in this repo.

In 42:51 I present a templates generator. I try to explain why I prefer to use templates instead of custom step types. I also show, more or less, how I organize my projects with Test Sequences and Driver Sequences (and how the latter are used during automatic templates generation). The demo can be found in this repo.

In 49:31 I show what we can accomplish with built-in TestStand Quick Drop and in 52:31 I show how to incorporate Sequence Editor controls events to implement custom Quick Drop for launching custom tools. The demo can be found in this repo.

In 58:09 I respond to chat questions:

• Demo of the startup script for Mike Webster;
• Linking *.tsenv with *.tsw in the startup script for Cyril Gambini;
• A comment regarding using Sequence Editor for Mathieu Reyrolle. I have additional clarification here. It is a good point that if you want to use Sequence Editor you need to have at least debug/deployment license. However, in many cases, this license type is selected by customers, because it gives them the ability to quickly respond to issues on the production. What is more, it is perpetual. So, having this in mind using Sequence Editor as the main GUI makes sense. But in any case, have a look at this guide to determine the best option for the use case;
• Regarding InstrumentStudio as a "Measurement Cockpit", you can have a look at this presentation and here (third video) for a simple example of running TestStand and InstrumentStudio side by side;
• Additional clarification for Mike Webster and Sam Roundy: *.tsenv works with custom Operator Interfaces without extra coding.

I tried to squeeze in a lot of information in this one-hour-long presentation. Therefore there are multiple takeaways one could take advantage of. Here are some of them:

• Use TestStand Environments! Using scripts is simple, do not require extra code and user will not see the difference. If you really can't stand scripts use TestStand API to automate this process (example in the presentation).
• Consider using Sequence Editor as the main GUI, both for development and execution. You don't need to maintain extra code and all you need is a little bit of time to configure it. Here is also a takeaway for NI: allow more Sequence Editor customization (and make UI Controls API consistent)!
• Another takeaway for NI would be: if you've taken the first step, and added Quick Drop to Teststand, take the second too, and take care of the real mouseless operation. Current Quick Drop is just a bare minimum and we still need to use the mouse a lot...
• Before NI takes care of the mouseless operation we can handle some cases with the approach I showed in the custom quick drop example. We can register events for Sequence Editor controls and implement our custom behavior.
• Last but not least: Templates. This simple tool can accelerate development time if properly incorporated.

The presentation was made using Marp for VS Code and it was a form of exercise with a new tool. You can access a live preview of it from this repo README.md file.

Michał Bieńkowski, February 2022