feat: Add steps APIs to the testmonitor client

[SSSantosh18]

• This contribution adheres to CONTRIBUTING.md.

TODO: Check the above box with an 'x' indicating you've read and followed CONTRIBUTING.md.

What does this Pull Request accomplish?

Include methods for nitestmonitor/v2/steps/ endpoints in testmonitor client

Why should this Pull Request be merged?

Steps APIs would be frequently used to extract measurement data from SystemLink for usage in custom scripts or notebook. So a Py client for that would make the script developer's life easy

What testing has been done?

Manual tested using a Py script

[SSadaiyappan-NI]

We have to include the api reference updates and example updates apart from the tests. If that is due to the dependency with the results PR, I will wait for the update for the next review

[SSSantosh18]

We have to include the api reference updates and example updates apart from the tests. If that is due to the dependency with the results PR, I will wait for the update for the next review

1. Added example
2. Added integration tests, Ideally result has to be created and used for step APIs, for now I have hardcoded the result ID. Will update this once Results API is merged
3. Yet to api reference updates

@SSadaiyappan-NI

[SSadaiyappan-NI]

Will wait for other changes in the PR

[SSadaiyappan-NI]

did we check if python bool works with c# type, when we pass it as query param @SSSantosh18 ?

[SSadaiyappan-NI]

We should confirm the behavior of the API before making this change. Please track this and update once we get an update

[priyadarshini-ni]

The change for this has been done in this PR. This change has been added here for the pipeline check

[rbell517]

I'd like to do better with the steps data than the anything goes the API allows. We have a standard set of fields to represent certain common parts of a measurement that would go here and the client should encourage using those. What I recommend is a new Measurement class with all the standard fields along with an extras dictionary for other stuff.

Here is what I would say is the ideal form.

class Measurement(BaseModel):
    name: Optional[str] = None
    status: Optional[Status] = None
    measurement: Optional[Union[str, int, float]] = None
    lowLimit: Optional[Union[str, int, float]] = None
    highLimit: Optional[Union[str, int, float]] = None
    units: Optional[str] = None
    comparisonType: Optional[str] = None
    extra: Dict[str, str] = {}

I say this is the ideal because I'm willing to compromise on this if it makes sense to, for example typing each field as string like it is on the API. I'm concerned about the performance cost for converting these to numeric types if the caller is pulling down a large number of steps with a large number of measurements. Keeping everything as strings would eliminate that. I also don't expect uplink to handle these unions well since the JSON is always going to be a string so it won't know to convert to a number, and neither would we, frankly, we'd basically be guessing.

cc @adamarnesen and @SSSantosh18 in case they want to add anything. In particular to know how string or numeric typing would impact the data frame we ultimately want to make.

[SSadaiyappan-NI]

Hi @rbell517 ,

We have added a config to allow extra fields to be added to the model apart from the ones already mentioned. But one drawback we see here is, we can't validate the types of the extra fields in the current pydantic version (1.10.2) we are using. If we have it as a dictionary like you mentioned, we may have to flatten it before sending it to create steps request and put the extra fields inside the extra after querying the steps. We feel that it may take a hit in the performance when we access the extra fields to flatten it and append it with existing data, if there are lot of measurements with extra fields.

If we just provide Extra: allow, we can allow extra fields.

1. If we need to validate fields, we may need to manually iterate through data of each measurement which might affect performance.
2. One more option is to check out the latest Pydantic version and its impact on upgrading it. It might allow us to set the types for extra fields.

Could you provide your thoughts on this?
FYI - @SSSantosh18

[SSadaiyappan-NI]

I have fixed the other comments and will wait for inputs on this for the re-review

[SSSantosh18]

@rbell517, on your first question to support the union of (Str | Int | Float), I think the measurement values can stay as string, so that no additional processing is done for each measurement by client.

Also, I assume when using this data to do analysis using pandas or other lib, they might be able to automatically identify the datatype and consider them as int, float. Please correct me if wrong