New Input/Output Functionality

This is some thing many of you have been asking about so I wanted to make sure all were aware, but also get some feedback.

Our previous input/output structure was based around a few things.

  1. An IInput<> type in one Test Step
  2. An [Output] attribute in another Test Step

Then based on the Types the Editor would allow for connection. This had a few limitations:

  1. Everything needed to be decided at Dev time (what will except Inputs and what will create Outputs)
  2. A Setting needed to choose being accepting an Input OR being manually set, it could not be both.
  3. If lots of inputs and outputs were used, the dropdown of options could be very large.

As of 9.10 we have fundamentally reworked this. The previous use case still exists for the very closely related steps, but in the more open ended and flexible case, we have pushed most of the up to the UI.

An Output attribute is still needed. In general, we encourage this to be used more. Anything that COULD be used, should be an output.

From there, the outputs can be mapped to inputs in code. You can see that in this gif:

I’m interested to hear what people think. Does this enable more use cases? Anything we still need to add?


@brennen_direnzo This looks like a major improvement. The 3 limitations you mentioned about the earlier Input/Output structure are the same reasons we never could make use of them.

We’ve hit several scenarios where we’d like to pass info from one step to another. We’ve always found a way around it, due to the limitations you identified. In one sense, this has been a good thing, because it forced us to think smarter about the general design, and impose as few requirements on the user as possible. Inputs & Outputs place more responsibility and requirements on the user, so overusing Inputs/Outputs would make the software less user-friendly.

Nonetheless, sometimes we have to pass info between steps. I was about to attempt to develop something conceptually similar to what you’ve shown here. My plan was to assign outputs directly from the step that produces the output. I think that’s what you’re showing here as well, correct?


@david-wsd your cautioning of over using Inputs/Outputs is why we have tried to not over use them (similar to Global Variables). Over usage generally is a sign of poor overall design that could create other issues. That said, there certainly are valid usages so we wanted to make those easier.

Your understanding is correct. If you use the [Output] attribute on any setting within a step it will then be available to pass into any other step setting.

Once you try it out, I’m interested to get your feedback especially since the previous implementation was something you avoided.


@brennen_direnzo @jeff.dralla As much as this is a strength of OpenTAP I also find it a weakness.
OpenTAP “forces” the user/developer to follow the philosophy of OpenTAP when developing testplans. Depending on background, history and requirements, it may require a lot of changes and modifications of testing and testplan strategy in order to adapt to OpenTAP.
The new Input/Output functionality is one big improvement making OpenTAP more flexible. Conditional testing, limit checking at testplan level and of course global and testplan variables are other areas for improvement making OpenTAP more flexible and easy to adapt.


@GoranJohnsson thanks for the feedback on Input/Output…extremely useful to get this validation from the community at large. We’ve been aware for sometime that this was a requirement to meet the needs of the wider community of automation-interested developers as @david-wsd and @brennen_direnzo have both noted, but just putting a short-term bandaid of global variables seemed like the wrong approach, at least for long-term success of OpenTAP.

There’s definitely some philosophical grappling that has to occur to get the best outcomes in these more fundamental topics and features. We hope/expect to have many more of such discussions here on the Forum, and why we are so excited to get such dialogue going with yourself and others!


@GoranJohnsson I certainly understand your perspective here, and you are not the first one to say this (as @jeff.dralla also mentions).

I believe this change of making it easier to pass values and allowing more flexibility (Setting values being manually set OR passed) is the first step to enabling the features you mention. Really this was a prerequisite to enabling other features.

There are certainly some tradeoffs, however, we do see features like you describe as necessary to support and grow the larger community. Particularly those trying to integrate with existing systems.

We will definitely keep you (and the rest of The OpenTAP Community) updated when this moves forward for early feedback.