Better string and object diffs

[jamestalmage]

The power-assert output is great except for long strings and moderate to large sized JSON objects.

I think for those cases, it is probably better to just output a diff. Something similar to mocha.

(I'm almost certain there was an issue raised about this already, but I couldn't find it quickly).

[sindresorhus]

Hah, opening an issue like this was already on my todo list. 👍 👍

Is this maybe something the power-assert reporter should handle?

[TrySound]

Related power-assert-js/power-assert#31

[jamestalmage]

Hmm. I don't know. It doesn't depend on powerAssertContext at all, just assertionErrror.expected and assertionError.actual, it certainly could be implemented as a custom reporter. I just don't know if that's the best choice.

// @twada

[twada]

It doesn't depend on powerAssertContext at all, just assertionErrror.expected and assertionError.actual

It makes sense when the assertion has two args (t.is, t.not, t.same, t.notSame).
With one arg (t.ok, t.notOk), power-assert should handle string diff and that's what BinaryExpressionRenderer does.

Rendering diffs between expected and actual could be handled by power-assert, and I'm thinking about implementing it though.

[jamestalmage]

Oh yeah, forgot about BinaryExpressionRenderer - we definitely want good diffs if they do:

t.true(someLongString === someOtherLongString)

How about extending BinaryExpressionRenderer with a "minimumLength" parameter that prevents short diffs from being displayed, a diff for t.true("foo" === "bar") is unnecessarily verbose, and it's easy to spot the difference looking at the power assert graph output.

[sindresorhus]

From Gitter, for posterity:

jamestalmage
@ben-eb power-asserts BinaryExpressionRenderer will output pretty diffs. So it would just be a matter of adding that in enhance.js.

ben-eb
@jamestalmage here? https://github.com/sindresorhus/ava/blob/master/lib/enhance-assert.js#L47-L52

jamestalmage 01:05
@ben-eb See the discussion in that PR. We don’t want BinaryExpressionRenderer to always show a diff. It’s too verbose.

ben-eb 01:06
i wouldn't either, no

jamestalmage 01:06
yep - that’s where.
I think the difficulty in fixing this is figuring out how to decide when to enable the BinaryExpressionRenderer.

ben-eb 01:07
so, is it possible to set a length at where diffs would render?
right

jamestalmage 01:08
It’s not possible in BinaryExpressionRenderer itself, but if you make a good PR that is general use (i.e. not exclusively targeted towards AVA). @twada will accept it. Our other option is to just wrap the renderer and delegate to it only if certain conditions are met.
I’m not sure if it’s as simple as string.length. It may be. Or you may need to examine the AST that is available in powerAssertContext that gets passed to the renderer.

ben-eb 01:10
what about this option? https://www.npmjs.com/package/power-assert-formatter#optionslinediffthreshold

jamestalmage 01:12
Yep - that looks key. Note that we don’t use that module. But build a formatter from individual renderers.
err - I’m wrong on that.

ben-eb 01:13
was going to say it's required in that file 😄

jamestalmage 01:14
We only use two of these five renderers
This may be doable with existing power-assert options.

ben-eb 01:18
think my only issue is that my string diffs don't have newlines, so I would want to be able to test against the length instead of the number of lines 😄

ben-eb 01:40
i didn't read that documentation properly, says it supports character level for lineDiffThreshold

ben-eb 03:17
sorry james, i'm completely lost with this.
i don't even know how i can break AVA's default assertions so that i can always show a diff

[twada]

@sindresorhus Oh thanks

[ben-eb]

I'd love this feature by the way, but I'm not at all familiar with AVA's code base...

[paulyoung]

As a workaround I've been doing this:

export const same = (t, actual, expected, message) => {
  return t.same(actual, expected, `

    ${message}

    Actual:
    ${JSON.stringify(actual, null, 2).split("\n").join("\n    ")}

    Expected:
    ${JSON.stringify(expected, null, 2).split("\n").join("\n    ")}

  `);
};

and then using:

same(t, actual, expected, message);

instead of:

t.same(actual, expected, message);

[vadimdemedes]

@paulyoung Good trick!

[novemberborn]

I've run into this lately. It makes it getting tests to pass quite cumbersome. Maybe we should step up the priority?

@twada are you saying this should be fixed in power-assert-renderers? Is it this issue: twada/power-assert-renderers#1? What can we do to help?

[twada]

@novemberborn I've started a new power-assert-runtime modules in a monorepo style and deprecate power-assert-renderers.

First alpha version is already published and the first beta version will be released soon, maybe this weekend.

@twada are you saying this should be fixed in power-assert-renderers? Is it this issue: twada/power-assert-renderers#1? What can we do to help?

Therefore, this issue would be fixed in new power-assert-runtime repo. I'll migrate power-assert-renderers issues to power-assert-runtime.

Sorry for inconvenience 🙇 Let's go forward together.