remove calls to set the timepicker in Lens tests, use default time

[LeeDr]

Summary

ref: #113998

These Lens tests had 85 calls to set the timepicker (all to the same default time) but the default time was already being set to that same time in the index file;

https://github.com/elastic/kibana/blob/main/x-pack/test/functional/apps/lens/group1/index.ts#L56
https://github.com/elastic/kibana/blob/main/x-pack/test/functional/apps/lens/group2/index.ts#L56
https://github.com/elastic/kibana/blob/main/x-pack/test/functional/apps/lens/group3/index.ts#L56

UPDATE: I reverted the changes to group2 and 3 because of test failures. I can probably remove most of the calls to PageObjects.lens.goToTimeRange() but I'll leave it to another PR.

UPDATE: Currently have removed 27 calls to goToTimeRange. Each call takes about 4.5 seconds on my laptop. So this PR should take about 2 minutes off the tests in lens/group1

[elasticmachine]

Pinging @elastic/kibana-qa (Team:QA)

[dej611]

UPDATE: Currently have removed 27 calls to goToTimeRange. Each call takes about 4.5 seconds on my laptop. So this PR should take about 2 minutes off the tests in lens/group1

That sounds great.
I was wondering whether it might make sense to leave the calls there in case the default date time changes, but add a check on top of the goToTimeRange method to check whether the time picker is already set at the right timing, and then exit earlier.

[LeeDr]

UPDATE: Currently have removed 27 calls to goToTimeRange. Each call takes about 4.5 seconds on my laptop. So this PR should take about 2 minutes off the tests in lens/group1

That sounds great. I was wondering whether it might make sense to leave the calls there in case the default date time changes, but add a check on top of the goToTimeRange method to check whether the time picker is already set at the right timing, and then exit earlier.

UPDATE: Currently have removed 27 calls to goToTimeRange. Each call takes about 4.5 seconds on my laptop. So this PR should take about 2 minutes off the tests in lens/group1

That sounds great. I was wondering whether it might make sense to leave the calls there in case the default date time changes, but add a check on top of the goToTimeRange method to check whether the time picker is already set at the right timing, and then exit earlier.

After a bunch of testing and trying to change setAbsoluteRange to check the current timepicker settings I found that defaultStartTime and defaultStartTimeUTC are off by 1 day. I don't think that was intentional. So I'm going to create a new PR to see if I can get tests to pass with those start times lined up. Once I see how that goes I'll come back to this.

defaultStartTime = 'Sep 19, 2015 @ 06:31:44.000';
defaultEndTime = 'Sep 23, 2015 @ 18:31:44.000';
defaultStartTimeUTC = '2015-09-18T06:31:44.000Z';
defaultEndTimeUTC = '2015-09-23T18:31:44.000Z';

[kibana-ci]

💔 Build Failed

• Buildkite Build
• Commit: dc8769d
• Interpreting CI Failures

Failed CI Steps

• Jest Tests #12

Test Failures

• [job] [logs] Jest Tests #12 / Response actions history With Data should refresh data when autoRefresh is toggled on

Metrics [docs]

Unknown metric groups

ESLint disabled in files

id	before	after	diff
osquery	1	2	+1

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
fleet	59	65	+6
osquery	109	115	+6
securitySolution	442	448	+6
total			+20

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
fleet	68	74	+6
osquery	110	117	+7
securitySolution	519	525	+6
total			+21

History

• 💚 Build #89748 succeeded b89a020
• 💚 Build #89689 succeeded 05ae409
• 💔 Build #89434 failed 7e71622
• 💔 Build #89406 failed c1dda99
• 💔 Build #89390 failed 62dd18f

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[LeeDr]

UPDATE: Currently have removed 27 calls to goToTimeRange. Each call takes about 4.5 seconds on my laptop. So this PR should take about 2 minutes off the tests in lens/group1

That sounds great. I was wondering whether it might make sense to leave the calls there in case the default date time changes, but add a check on top of the goToTimeRange method to check whether the time picker is already set at the right timing, and then exit earlier.

I've done this in (not yet merged) #146462 if you would like to review that.