[Draft] MNSTR-5245: Measure App Header render time #58
Conversation
|
Thank you for your submission! Like many open source projects, we ask that you sign our CLA (Contributor License Agreement) before we can accept your contribution. Already signed the CLA? To re-check, try refreshing the page. |
| ), | ||
| actionMeter = ActionMeter.Builder(AppendableActionMetricOutput(segment.actionOutput)) | ||
| .virtualUser(segment.id) | ||
| .appendPostMetricHook(DrillDownHook(JavascriptW3cPerformanceTimeline(segment.driver.getDriver()))) |
There was a problem hiding this comment.
You didn't need that for testing. Any Scenario (e.g. one in jira-actions module or in any other repo) can override the ActionMeter passed onto its actions. And you can create a modified copy of any ActionMeter via its Builder
There was a problem hiding this comment.
Oh, didn't think about that, I should have asked earlier x)
So where do you think should the hook be placed finally - here or in the com.atlassian.jira.test.performance.scenario.AllActionScenario?
There was a problem hiding this comment.
The ActionMeter already has default postMetricHooks as an empty list. The JavascriptW3cPerformanceTimeline should remain opt-in, because it has a big storage and transfer overhead. So basically, it should not be put in to any JPT API.
The end-consumers like our internal regression tests or hardware recommendations can opt-in if they want to. You already opted-in the AbstractJiraCoreScenario (just tests, not API) in jira-actions, so it got covered by the JiraCoreScenarioIT integration test. 👌
PS. now I also see that there's a dedicated JiraCoreScenarioDevloop in there for fast local devloop.
There was a problem hiding this comment.
In general, each JPT lib should be self-sufficient in terms of devloop. There's a high chance it already has the necessary testing harness. If not, it should be added/extended.
2 participants
For atlassian/jira-actions#93