This should emit an event, right?

yes, timestamp event.

You need to call kEmitMessage in order to actually emit the event.

Ahh, I see. I will correct that.

something like this:
opts.root.reporterkEmitMessage;

Not quite, in the timeStamp function, you should call this[kEmitMessage]. Look at the other methods for reference

Is there a case where timeStamp won't be callable? I don't think so?

Yes, there is no case, because it is only called when the --watch flag is used, and the only condition for it to be triggered is when there is a change in the test file or the file being tested.

But what if there is no actual change in the test case result? It still runs regardless.
This goes beyond the scope of this issue. I would have to modify the working process of file_watcher.js for the --watch flag so that --watch would not be triggered unless there is a change in the actual test result — based on a comparison with the previous result (from the code being tested).

I think you misunderstood. I'm saying you don't need the if clause since there isn't a case where that function isn't callable (it's never undefined)

Oh, yeah, it is never undefined. I will take that out.
Thanks for the feedback.

is this not something that needs to be worked on tho?

But what if there is no actual change in the test case result? It still runs regardless.\nThis goes beyond the scope of this issue. I would have to modify the working process of file_watcher.js for the --watch flag so that --watch would not be triggered unless there is a change in the actual test result — based on a comparison with the previous result (from the code being tested).

You are calling the mustCall, you should make the event's callback the mustCall instead (on(something, common.mustCall()))

Yes, you are right. I would also have to add about three lines of code that make actual changes to the file being tested.
But this cuts off the test and restarts it. There no way for me to make an actual change to the file being tested without the test execution not generating an error.

Previous Detail: this run on --watch
Here is the previous test code I wrote:

const fs = require('fs');
const { run } = require('internal/test_runner/runner');
const { parseCommandLine } = require('internal/test_runner/utils');
const { join } = require('path');
const common = require('../common');
const assert = require('assert');

const testFile = join(__dirname, '../fixtures/test-runner/test_only.js');

const options = {
...parseCommandLine(),
globPatterns: [testFile],
watch: true,
isolation: 'process',
cwd: __dirname,
};

const reporter = run(options);

let timeStampCalled = false;

reporter.timeStamp = common.mustCall((type, data) => {
assert.strictEqual(type, 'test:restarted');
assert.ok(data.file);
timeStampCalled = true;
});

reporter.on('test:summary', common.mustCall((data) => {
assert.ok(data);
assert.ok(typeof data.success === 'boolean');
assert.ok(timeStampCalled, 'Expected timeStamp to be called before summary');
}));

// Trigger file change after 500ms to activate watch mode
setTimeout(() => {
fs.appendFileSync(testFile, '\n');
}, 500);

// Failsafe timeout
setTimeout(() => {
if (!timeStampCalled) {
console.error('[Test] FAIL: timeStamp() was not called in time');
process.exit(1);
}
}, 3000);

Hey @OkunadeNaheem , we already have the restart event being dispatched here

How do I utilise the timestamp feature?
Tho I saw that some changes were made by @JacopoPatroclo but I did not see how to utilise, so I thought the changes was not a solution for the timestamp feature.

I think that this logic should be placed as part of the reporters, as a user might want to avoid this message in their report

I think that we might want to test the output of the runner instead of the TestsStream itself!