While writing adapters and tests, I find myself running into confusing diffs and return values due to objects like { foo: 1, bar: undefined } turning into { foo: 1 } after standard JSON serialisation, because undefined is not valid in JSON.
I'm proposing to change our use of undefined in the spec to null instead.
Specifically:
SuiteStart.name: From string|undefined to string|null, where null is the global suite.
SuiteEnd.name: From string|undefined to string|null.
TestStart.suiteName: From string|undefined to string|null.
TestEnd.suiteName: From string|undefined to string|null.
There is one more mention of undefined in event data, namely for Assertion.stack.
string|undefinedstack: Optional stack trace. For a "passed" assertion, it is always undefined.
Unlike for global suites, where undefined is somewhat meaningful, I think for assertions the undefined here was meant to allow implementers to omit the property, although it doesn't say that currently. From a lazy perpective though, absence and setting to undefined are mostly the same thing. Requiring setting of null as fallback would move further away from optional properties.
For this one, I'm proposing to introduce our first truely optional event data property and specify Assertion.stack as optional property of type string. In practice, setting undefined or null will likely be compatible with most reporters, but we wouldn't recommend that.
While writing adapters and tests, I find myself running into confusing diffs and return values due to objects like
{ foo: 1, bar: undefined }turning into{ foo: 1 }after standard JSON serialisation, becauseundefinedis not valid in JSON.I'm proposing to change our use of
undefinedin the spec tonullinstead.Specifically:
SuiteStart.name: Fromstring|undefinedtostring|null, where null is the global suite.SuiteEnd.name: Fromstring|undefinedtostring|null.TestStart.suiteName: Fromstring|undefinedtostring|null.TestEnd.suiteName: Fromstring|undefinedtostring|null.There is one more mention of
undefinedin event data, namely forAssertion.stack.Unlike for global suites, where
undefinedis somewhat meaningful, I think for assertions the undefined here was meant to allow implementers to omit the property, although it doesn't say that currently. From a lazy perpective though, absence and setting to undefined are mostly the same thing. Requiring setting ofnullas fallback would move further away from optional properties.For this one, I'm proposing to introduce our first truely optional event data property and specify
Assertion.stackas optional property of typestring. In practice, setting undefined or null will likely be compatible with most reporters, but we wouldn't recommend that.