Extend Assert#pushResult to receive a custom diff value

[leobalter]

trafficstars

As requested by @wycats, it would be good to extend Assert#pushResult to receive a custom diff value, where it does not replace the default QUnit.diff (still useful for other assertions) but it prints a customized diff value.

Examples:

// Using default diff
QUnit.assert.prototype.customAssertion1 = function(actual, expected, result = actual == expected) {
  return this.pushResult({result, actual, expected});
};

// Using custom diff
QUnit.assert.prototype.customAssertion2 = function(actual, expected, result = actual == expected) {
  return this.pushResult({
    result,
    diff: lineDiff(actual, expected)
  });
};

If diff is given, QUnit should get its value and ignore calling the default QUnit.diff.

[wycats]

Straw man:

interface Diff {
  kind: 'line' | 'word',
  expected: string,
  actual: string
}

It would also be great to have a lower-level interface we could use to specify the differences in a format like this:

[
  { "type": "context", "line": "..." },
  { "type": "removed", "line": "..." },
  { "type": "added", "line": "..." },
  { "type": "context", "line": "..." }
]

[leobalter]

That's a bit more complex than my initial proposal but I'm interested on seeing this implemented.

@gibson042 @trentmwillis what do you think?

[wycats]

@leobalter I'm fine with any level of abstraction :smile:

I just fleshed out perhaps an Ultimate(tm) version of the feature.

[trentmwillis]

This seems reasonable to me. A couple thoughts:

• Should a diff value or function be passed in? If a function were to be passed instead (with a pre-determined signature) we could avoid doing early (and potentially unnecessary) work.
• We sort of have the lower-level interface already, where diffs are represented by tuples. Does this suffice or can we workshop it a bit? If we leverage the existing pattern, it would be easy to get a pluggable diffing function that also gets the existing HTML Reporter formatting for free.

[gibson042]

I'm not ready to accept this particular low-level strawman now, but I like extending pushResult's argument to include diff data that overrides/replaces actual and expected. And I can see different reporters wanting different formats (e.g., HTML vs. ANSI-escaped vs. patch vs. structured tuples vs. …), so a function or an object with methods (which I suppose toString is implicitly) is also more appealing to me than a string value.