You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add endTime property to TestResult which would be the end time of this particular test run.
(and probably add it to TestStep as well)
Example
No response
Motivation
Currently testResult.startTime + testResult.duration is smaller than the actual end time. So computing the end time from these two properties is not accurate.
In our use case, we need a more accurate timestamp because we match server logs to a specific test based on time.
Test showing this behaviour
test('should approximate end time from with startTime + duration',async({ runInlineTest })=>{constresult=awaitrunInlineTest({'reporter.ts': ` class Reporter { onTestEnd(test, result) { console.log('%%start=' + result.startTime.getTime()); console.log('%%duration=' + result.duration); } onStdOut(data) { // forward test stdout so %%actualEndTest lines reach outputLines process.stdout.write(data.toString()); } } module.exports = Reporter; `,'playwright.config.ts': `module.exports = { reporter: './reporter' };`,'a.spec.ts': ` import { test } from '@playwright/test'; test('timing', async () => { await new Promise(f => setTimeout(f, 250)); console.log('%%actualEndTest=' + Date.now()); }); `,},{reporter: '',workers: 1});conststart=Number(result.outputLines.find(l=>l.startsWith('start='))!.split('=')[1]);constduration=Number(result.outputLines.find(l=>l.startsWith('duration='))!.split('=')[1]);constactualEndTest=Number(result.outputLines.find(l=>l.startsWith('actualEndTest='))!.split('=')[1]);constreportedTestEnd=start+duration;constdelta=actualEndTest-reportedTestEnd;constdateToTime=(ms: number)=>newDate(ms).toISOString().slice(11,23);// HH:MM:SS.mmmconsole.log([`start\t\t${dateToTime(start)}`,`reportedEnd\t${dateToTime(reportedTestEnd)}`,`actualEnd\t${dateToTime(actualEndTest)}`,`durationMs\t${duration} ms`,`deltaMs\t\t${delta} ms`,].join('\n'));});
Currently testResult.startTime + testResult.duration is smaller than the actual end time. So computing the end time from these two properties is not accurate.
what will endTime include that start + duration does not cover?
what will endTime include that start + duration does not cover?
Well maybe it is actually a bug with duration (I have not yet looked deep in the playwright code), but testResult.startTime + testResult.duration should definetely be equal or large than actualEndTest in above example.
Chris (@cpAdm)duration does not include things like beforeAll hooks or worker-scoped fixtures. Unfortunately, there is no good solution here - we want to both keep duration only include test-specific timings, but that does not necessary aligns with calling Date.now() in various places of the test.
Dmitry Gozman (@dgozman) Tricky. Maybe lets keep duration as is (for backwards compatibility), but add endTime which more closely reflects the actual end time?
It's a bit more tricky, since all tests run in parallel (so matching the logs isn't one-to-one to begin with). But I guess we could use parallelIndex to find the right next test for the current worker.
(Currently we don't shard tests so missing shardIndex#38962, is not an issue.)
I've been looking at this and I think the right fix is at the IPC layer rather than trying to derive the end time from duration.
Currently TestBeginPayload transmits startWallTime but TestEndPayload has no corresponding endWallTime, so the worker knows exactly when a test ended but throws that timestamp away. Since duration intentionally excludes beforeAll hooks and worker-scoped fixture teardown, no amount of math on the reporter side can recover the true wall-clock end time.
The fix would be to add endWallTime to TestEndPayload in ipc.ts, populate it in the worker at the moment the end message is sent, propagate it through the dispatcher into a new endTime field on TestResult, and expose it in the public reporter API and HTML report.
I'd like to implement this if the team is open to it
I was also struggling to calculate the exact timings for testBody start/end. With some math it's possible on the current data, but it's rather complex. Having these timings in the reporter API would be very helpful.
I agree that this would be appreciated, I could make use of an accurate endTime to include logs given by different traces tools when a test fails, only matching the correct time spawn and user
We're closing all P3-collecting-feedback issues and retiring the label. #43813 explains why. This doesn't mean the request is wrong. If it still matters to you, please open a new issue against the latest Playwright version with your concrete use case and link back here.
Activity
pavelfeldman commentedon Mar 15, 2026
what will endTime include that start + duration does not cover?
cpAdm commentedon Mar 17, 2026
Well maybe it is actually a bug with
duration(I have not yet looked deep in the playwright code), buttestResult.startTime + testResult.durationshould definetely be equal or large thanactualEndTestin above example.dgozman commentedon Mar 24, 2026
Chris (@cpAdm)
durationdoes not include things likebeforeAllhooks or worker-scoped fixtures. Unfortunately, there is no good solution here - we want to both keepdurationonly include test-specific timings, but that does not necessary aligns with callingDate.now()in various places of the test.cpAdm commentedon Mar 25, 2026
Dmitry Gozman (@dgozman) Tricky. Maybe lets keep
durationas is (for backwards compatibility), but addendTimewhich more closely reflects the actual end time?dgozman commentedon Mar 25, 2026
Chris (@cpAdm) Well, that would raise questions of why
startTime + duration !== endTime😄For your usecase, could you consider everything between two consecutive
startTimevalues as belonging to the first test?cpAdm commentedon Mar 25, 2026
Dmitry Gozman (@dgozman) Fair point, although one could document why this is the case.
It's a bit more tricky, since all tests run in parallel (so matching the logs isn't one-to-one to begin with). But I guess we could use
parallelIndexto find the right next test for the current worker.(Currently we don't shard tests so missing
shardIndex#38962, is not an issue.)areebmohammed commentedon May 5, 2026
I've been looking at this and I think the right fix is at the IPC layer rather than trying to derive the end time from duration.
Currently TestBeginPayload transmits startWallTime but TestEndPayload has no corresponding endWallTime, so the worker knows exactly when a test ended but throws that timestamp away. Since duration intentionally excludes beforeAll hooks and worker-scoped fixture teardown, no amount of math on the reporter side can recover the true wall-clock end time.
The fix would be to add endWallTime to TestEndPayload in ipc.ts, populate it in the worker at the moment the end message is sent, propagate it through the dispatcher into a new endTime field on TestResult, and expose it in the public reporter API and HTML report.
I'd like to implement this if the team is open to it
vitalets commentedon May 6, 2026
I was also struggling to calculate the exact timings for testBody start/end. With some math it's possible on the current data, but it's rather complex. Having these timings in the reporter API would be very helpful.
Az8th commentedon Jun 29, 2026
I agree that this would be appreciated, I could make use of an accurate endTime to include logs given by different traces tools when a test fails, only matching the correct time spawn and user
pavelfeldman commentedon Oct 31, 2026
We're closing all
P3-collecting-feedbackissues and retiring the label. #43813 explains why. This doesn't mean the request is wrong. If it still matters to you, please open a new issue against the latest Playwright version with your concrete use case and link back here.