Enabled attribute not available in test steps created in Python

I’ve noticed that test steps created in Python, including the examples, don’t have Enabled parameter exposed to the UI in the step settings. At the same time, Break Conditions and Description attributes coming from the base test step are exposed properly. Adding this attribute explicitly seems to confuse OpenTAP completely. Does anyone know what causes this behavior and whether there’s a workaround?

1 Like

Because of the generic types used in the C# version of Enabled this is implemented slightly different than the standard attributes. You can see an example here:

Are you saying that Enabled attribute won’t come from the base TestStep class and it needs to be added explicitly (similar to the provided example)?

That is not what I meant, but is that the behavior you are seeing? I was just trying to say that handling those types is a little different (OpenTap.Enabled):

logging = self.AddProperty("Logging", OpenTap.Enabled[String](), OpenTap.Enabled[String])

And you also have to import the .NET types:

from System import Array, Double, Byte, Int32, String, Boolean # Import types to reference for generic methods   

Yeah, that’s the behavior I’m seeing. Maybe my initial message was not so clear but I was talking about TestStep.Enabled attribute, not OpenTap.Enabled datatype :slight_smile:

1 Like

So you’re talking about the property, not the attribute?


@pythonized ok thanks for the clarification. I see what you mean now. That does appear to be a bug, and I have submitted it here:

You can of course enable/disable the Test Step manually from the Test Plan Panel.

1 Like

@john.berlien Thanks for the correction, I meant the property indeed. The attribute is actually there.

1 Like

As a workaround, it seems to work if property and attribute are added to the step explicitly:

        self.AddProperty("Enabled", True, Boolean).AddAttribute(OpenTap.DisplayAttribute, "Enabled", "", Group="Common", Order=20000, Collapsed=True).\
        AddAttribute(OpenTap.ColumnDisplayNameAttribute, "", Order=-101)

@brennen_direnzo It seems that there’s a similar issue with TestStep.Name. I couldn’t find a good workaround for that one though. I can add it explicitly as TestStep.Enabled but I’m not really able to make use of it. Namely, I can set self.Name but it doesn’t have any effect. I’ve also tried using OnPropertyChanged but with no luck.

My use case is to have different display name and regular name like in Sweep Parameter step: Sweep Parameter vs Sweep {Parameters}.


Where are you trying to update this? DisplayName is generally the right place to make these changes, but they aren’t really intended to be dynamically updated outside of using “{ }” in the DisplayName

1 Like

@brennen_direnzo Ah I mixed it up I think. Actually it’s DisplayName that is missing and it can be fixed the same way as Enabled!

self.AddProperty("DisplayName", "", String).\
            AddAttribute(OpenTap.DisplayAttribute, "Step Name", "", Group="Common", Order=20001, Collapsed=True).\
            AddAttribute(OpenTap.ColumnDisplayNameAttribute, "Name", Order=-100)

You should also be able to add the DisplayAttribute like this:

@Attribute(DisplayAttribute, Name="Charge", Description="Simulated scenario of an emulated power analyzer charging a battery and measuring the voltage curve.", Groups= ["Python Example", "Battery Test"])
class ChargeStep(SamplingStepBase):

@brennen_direnzo Not sure I fully understand your idea :slight_smile: To my best knowledge, applying this decorator to a test step will only set TestStep.Name and at the moment there’s no way to set DisplayName unless it’s added explicitly like Enabled.

In this case DisplayAttribute Name == DisplayName (as in the name that will appear in the Editor). It should accomplish the same as your code, just in a slightly simplified way

My original idea was to have Name != DisplayName. Is it possible to accomplish that this way? My experiments show that setting TestStep.DisplayName doesn’t have any effect unless the suggested code is added.

I see. Then your implementation makes sense.

1 Like