Add grouping to measurements.

[jettisonjoe]

No description provided.

[grybmadsci]

Hm, details? Do we still need this?

[fahhem]

I've actually wanted this in tests I've written, I have a bunch of power-related measurements, serial-related, ethernet-related, etc and I'd like them to be grouped together instead of mixed in any UI that I can access.

What I was thinking of doing was group them by the phase, but that won't help with phase re-use (the name is the same but the measurements should be separated) nor with multi-phase grouping. Here's a couple strawman APIs:

@(measures(...).Group('power'))  # or Grouping or GroupBy?
# or
@measures.Group('power')(...)

The first seems like it would be good? You could even chain them to have multiple groups in the same phase. It requires the extra () to deal with Python syntax, I checked :(

[jettisonjoe]

I don't think my group has a particular need for this at the moment, but I can see it being useful. The new test UI as designed breaks things down primarily by phase. We would need to add a new view to support group-based measurement display.

If groups aren't going to be mutually exclusive, I think we should consider calling them 'tags', since #tags are a concept that most internet users are already familiar with.

Regarding API, I would suggest something simple like:

@measures(
    Measurement('vegeta_power_lvl').Tags('power'),
    Measurement('goku_power_lvl',
                tags='power'))  # We talked about doing something like this, right?

[fahhem]

I like your examples, Joe!

My thinking was they would be exclusive, but if there's a use case for
non-exclusive then tags seems good. Even putting the # in the name if we
want to go full-millenial :)
On Apr 5, 2016 1:25 PM, "Joe Ethier" notifications@github.com wrote:

I don't think my group has a particular need for this at the moment, but I
can see it being useful. The new test UI as designed breaks things down
primarily by phase. We would need to add a new view to support group-based
measurement display.

If groups aren't going to be mutually exclusive, I think we should
consider calling them 'tags', since #tags are a concept that most internet
users are already familiar with.

Regarding API, I would suggest something simple like:

@measures(
Measurement('vegeta_power_lvl').Tags('power'),
Measurement('goku_power_lvl',
tags='power')) # We talked about doing something like this, right?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#10 (comment)

[grybmadsci]

+1, I like Joe's syntax examples, and they map nicely to the inline-spec version, too:

@measures('gohan_power_lvl', tags='power')

IIRC guzzle TestRun proto already has tags for measurements, or is that just for the TestRun as a whole? Either way, we could add the tag to the measurement metadata we output :)

[glados-verma]

To keep things simple, we're currently keeping measurements "flat" (no second "dimensions" like tags or group). This functionality is nice but not often needed. For complex testers we recommend recording data in structured formats like JSON.