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.
- An
IInput<> type in one Test Step
- An
[Output] attribute in another Test Step
Then based on the Types the Editor would allow for connection. This had a few limitations:
- Everything needed to be decided at Dev time (what will except Inputs and what will create Outputs)
- A Setting needed to choose being accepting an Input OR being manually set, it could not be both.
- 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?
6 Likes
@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?
2 Likes
@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.
2 Likes
@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.
3 Likes
@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!
3 Likes
@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.
2 Likes
I’ve finally started playing with these Inputs and Outputs. One quick observation: I initially forgot to “new” my Input property in my Step constructor, and that sent me down a dark road for about and hour. 
So this is just a heads up for everyone, don’t forget to new your Inputs in the Step constructor.
Here’s how my drama unfolded:
I couldn’t figure out why the input’s dropdown was always empty, no output available to select (now I know it’s because my Input was null).
Somewhere in the process, I saved my test plan, which cemented my Input as null in the TapPlan xml.
Later I realized I needed to new my Input in the constructor, so I added that. But my step settings still showed an empty dropdown. Finally I realized the TapPlan xml was setting it back to null. So I ultimately deleted the test step and added it back in again, and was finally able to select an Output.
3 Likes
Well, this is pretty cool. I love the Assign Output option, so any property can be optionally linked to an Output.
@brennen_direnzo Is there a way to determine programmatically whether a property has been assigned an Output or not?
1 Like
I’m actually not sure. @rolf_madsen is this possible?
Sure. I think the most straightforward way is by using InputOutputRelation.IsOutputAssigned / InputOutputRelation.IsInputAssigned.
1 Like
Hi,
Jumping on an old thread here, but I need some help in using Inputs. I have a test step that has an output of type List<uint>. I need to pass this to another TestStep as an input. In the legacy code, the List is simply passed between code modules and a particular element is accessed using the [ ] operator.
Currently, on my second test step, I created the Input as such: Input <List<uint>> myList {get; set;} The problem is that I don’t know how to access the element I need. When the input is a discrete value such as Input<double> myDouble, this is easy as the value is simply myDouble.Value … But how do i access a certain element of this list? I tried something like myList[1].Value … but that doesn’t work.
In short, how do we deal with Inputs that are arrays or Lists?
You can disregard this question. I got the answer, I can index it like this:
myList.Value[1]
3 Likes
