Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Ability to show only changes and deletions in diffs, not additions

See original GitHub issue

I use chai assertion library and chai-like library for the partial comparing of objects: I am interested in existence and compliance only of those properties that are listed in an expected object. Existence of additional properties in an actual object permissibly. Unfortunately, when diff is created it is not considered in any way and those properties, existence which for the test it is indifferent get to diff. It would be desirable to have a way to suppress their generation in a diff. Example (runned with mocha):

'use strict';

let chai = require('chai');
let expect = chai.expect;
chai.use(require('chai-like'));

describe("diff test", function() {
  let AST = {
    type: 'grammar',
    rules: [
      { type: 'rule', name: 'rule1' },
      { type: 'rule', name: 'rule2' },
    ],
    // it is a lot more other properties
  };
  it("chai-like", function() {
    expect(AST).like({
      rules: [
        { name: 'rule' },
        { name: 'rule2' }
      ]
    });
  });
});

This is current actual output of mocha which is too large in some cases and contains unnecessary details

  1) diff test
       chai-like:

      AssertionError: expected { Object (type, rules) } to be like { Object (rules) }
      + expected - actual

       {
         "rules": [
           {
      -      "name": "rule1"
      -      "type": "rule"
      +      "name": "rule"
           }
           {
             "name": "rule2"
      -      "type": "rule"
           }
         ]
      -  "type": "grammar"
       }

      at Context.<anonymous> (test\test.js:24:17)

But I want that diff looked here so:

 {
   "rules": [
     {
-      "name": "rule1"
+      "name": "rule"
     }
   ]
 }

Now there is no opportunity to show diff in that look in what it is required as AssertionError has no signs that it is required. Mocha developers advised to create at first the task here before they are able to support this functionality (https://github.com/mochajs/mocha/issues/3193).

I suppose add to an AssertionError object new property which could control such behavior of diff.

If the idea is supported, I can make PRs for its implementation in all necessary libraries.

Issue Analytics

State:
Created 6 years ago
Comments:27 (21 by maintainers)

Top GitHub Comments

2reactions

keithamuscommented, Jan 15, 2018

You can see these issues have been surfaced with a fairly regular cadence since 2014 which is somewhat shortly after when mocha started supporting expected and actual.

We can see the same thing in Mocha’s issue tracker: https://github.com/mochajs/mocha/issues/1832, https://github.com/mochajs/mocha/issues/1348, https://github.com/mochajs/mocha/issues/1071 … I won’t go on, you know enough about mocha’s issues.

All of these issues are roughly duplicates of eachother - the general theme is that the error output isn’t sufficient.

requested by a single individual

FWIW @Mingun is looking for the same answer all the above issues are. I’m derailing this issue with my own agenda, which is something I’ve been perculating on for a long time. I’ve been hoping to add diff for a long time, not just because of this recently filed issue.

interop

That is exactly what I’m after. Given mocha+chai is the most used combo, like you say, we could easily throw a bit of weight around and end up with everyone happy. IMO this is where the diff property would help. It would not break backward compat, and libraries could simply opt into it where they want to. But maybe I’m just flogging a dead horse now, so let’s restart.

Problem

Both mocha and chai need to improve diff output, to stop the influx off issues we both receive. How do we do this in an interoperable way?

Requirements (chai)

We have to inspect objects and convert them to strings for our .message property (we call this lib loupe, it is going through a huge rewrite currently)
Future versions of loupe will use object-diffing as a heuristic for providing concise and effective .message strings.
loupes algorithms can be used to represent the differences between two objects, in some format, object or string.

What are Mocha’s requirements for this interop here?

1reaction

boneskullcommented, Jan 17, 2018

brain dump follows

Where Do I File A Bug?

What sucks for users, I’ve noticed, is that they don’t know which lib is responsible for the diff. Is it Chai? Is it Mocha? Sometimes we don’t even know!

I’m open to suggestions on how to attack that.

Baseline Value Representation

What also sucks–and could suck more, if we don’t do this right–is inconsistent diffs from one lib to the next.

How to represent a numeric primitive is not especially controversial. But …

How to represent a Number instance? What about String?
How do we represent a value that doesn’t exist, e.g. undefined or void 0?
How about null?
How do we diff Date objects?
Buffer objects? ArrayBuffer objects? SharedArrayBuffer objects (j/k)?
Promise objects? Non-native Promise objects?
In what way does this output change if we do deep object comparison?
When is deep object comparison unnecessary? What about if the “types” differ?
Any considerations for environments not fully supporting ES2015+?
How do we treat Arrays vs array-like objects? What’s considered an array-like object?
What about Map, and Set?
And WeakMap and WeakSet, both of which cannot be enumerated?
What about a strict equality check against two “equivalent” objects (e.g. {foo: 'bar'} is not the same object as {foo: 'bar'}, but it’s equivalent)?

Mocha has its own ideas about many of these, but not necessarily the “best” or “most correct” ones. Some of these may be best left out of the “core”–and/or we can choose to delay decisions until they become necessary.

In short, getting on the same page in terms of a subset of value representation is needed from a UX standpoint.
We also need to define the “general” case, whether that’s JSON diffs or whatever.
We may be able to consume the same base library for this.

Extensibility

…but there’s likely more than one way to represent any of the given types I’ve mentioned above. Different kinds of diffs–not just object comparison–may (?) need support, such as a standard unified or inline output from diff.
A lib or plugin author should be able to write their own custom implementation to diff objects of a certain “type”. This can be defined by instanceof, or type, or a custom comparison function.
Going a step further, end users should be able to leverage a valueOf()-like-function to tailor the diffs to their liking, so you don’t need to do a Magic Plugin Dance to get that diff for your MonkeyButt class looking the way you want.

Metadata, Statistics

One thing Mocha can’t do, because of a lack of a built-in assertion library, is set an expectation about how many assertions were expected to be made. Mocha doesn’t know what an “assertion” is. Some may find this capability more useful than others, but it is another tool to avoid false positives.

But I don’t know if the user should touch the assertion lib API or Mocha’s API to use it.

(This is also not currently possible from within a standalone assertion framework, because it doesn’t know when a “test” or “suite” finishes. Or what a “test” or “suite” is.)

Open to ideas. First thing that comes to mind is some sort of EventEmitter bus.

If there are numbers that Chai keeps that may be useful to Mocha, let’s expose those.

Backwards Compat

Mocha must continue to work fine with other assertion libraries. That said, Mocha’s diff output will necessarily change, since I don’t want to maintain two separate algorithms for this.

Modules

Given that currently an assertion library can create and display the entire diff without any assistance from Mocha short of a console.log(message), I’m not sure what Chai expects Mocha to implement. @keithamus mentioned “colors”, etc., but this is not something Mocha must do because Chai cannot. What I’m looking for is to understand:
- What (relevant) responsibilities Chai does not want
- What (relevant) responsibilities Chai wants to delegate to another module
As mentioned earlier, Mocha & Chai could consume the same module to generate diffs.
- Could the “diff module” be swapped out?
- Are “diff plugins” reasonable? Are they plugins to the “diff module”?
- A separate module & plugins could make it more difficult for end users b/c they really won’t know where to file an issue