RuleTesters AssertionError.actual is not being displayed

[florianb]

Hey, i am stucked implementing the fix for avajs/eslint-plugin-ava#21

I am not able to debug my fix since ava outputs only the expected value alongside with the error message:

no-only-test › invalid: const test = require('ava');
test.cb.only(t => { t.pass(); t.end(); });
  /...rule-tester.js:502

  Output is incorrect.
...

I tried to find out how to fix that and i was even thinking about patching eslint, to let the error message contain more information. Digging deeper i found out that RuleTester uses the common assert library's equal to match the expected output with the fixResult.output. For me it seems like Ava should also print error.actual in the case a fix-rule is tested.

I was currently not able to find out where the best look for a point to improve the output of eslints-fix tests. And i somehow thought this might be the rightplace since #3 discusses a topic around fixes, too.

I would appreciate any hint how to improve this.

[sindresorhus]

This looks to be a problem with AVA, but for now we can workaround it with:

'use strict';

var RuleTester = require('eslint').RuleTester;

module.exports = function (test, options) {
  RuleTester.describe = function (text, method) {
    RuleTester.it.validity = text;
    return method.apply(this);
  };

  RuleTester.it = function (text, method) {
    test(RuleTester.it.validity + ': ' + text, () => {
      try {
        method();
      } catch (err) {
        err.message += `\n\nActual:\n${err.actual}\n\nExpected:\n${err.expected}`;
        throw err;
      }
    });
  };

  return new RuleTester(options);
};

@jfmengels Would you be open to a pull request?

[sindresorhus]

@novemberborn How should we handle this in AVA? I guess this becomes more complicated now that we prerender the assertion messages.

[novemberborn]

How should we handle this in AVA? I guess this becomes more complicated now that we prerender the assertion messages.

My in-progress formatter would show additional error properties, besides just the name and message. That would be the generic fix.

We could also recognize arbitrary AssertionErrors and extract presumed standard properties, mapping them into our internal AssertionError.

[sindresorhus]

We could also recognize arbitrary AssertionErrors and extract presumed standard properties, mapping them into our internal AssertionError.

Yes, we should do that. actual and expected is the general convention.