So, duplicate error messages

[wizardwerdna]

The drivers (and this may be a driver issue) working with Jasmine 1.X would result in concise assertion failure reports along the lines of:

PhantomJS 1.9.8 (Mac OS X) ngFromHtml() should work for simple dynamic html FAILED
        Expected '' to be '2'.
PhantomJS 1.9.8 (Mac OS X): Executed 4 of 4 (1 FAILED) (0.005 secs / 0.022 secs)

However, under Jasmine 2.x, we get duplicated errors messages:

PhantomJS 1.9.8 (Mac OS X) ngFromHtml() should work for simple dynamic html FAILED
        Expected '' to be '2'.
        Error: Expected '' to be '2'.
            at /Users/werdna/wiz-dev-env/test/environment.js:33
            at /Users/werdna/wiz-dev-env/node_modules/karma-jasmine/lib/boot.js:126
            at /Users/werdna/wiz-dev-env/node_modules/karma-jasmine/lib/adapter.js:171
            at http://localhost:9876/karma.js:189
            at http://localhost:9876/context.html:49

The latter yields overlong messages and lots of undesireable cruft.

Whaddya think? I'm happy to research this, but perhaps there is a simple and obvious solution my colleagues may provide?

[maksimr]

@wizardwerdna hi!

I think it because jasmine@2.x change error message format:

You can try fix it here

Thanks!

[wizardwerdna]

Yep, that's the ticket. Of course, I could parse the message, eliminate "Error:" and return from inside there, but I think the fix should happen somewhere deeper in the jasmine.js file, when a stack is being returned, but shouldn't be, or something like that. I'm loathe to take the easy solution if something simpler is available.

In the Jasmine 1.0 code, the failed message returns with no stack trace, so the if(stack) is not executed. I just can't grok what's going on inside. Anybody more clueful than I?

[wizardwerdna]

Well, its trickier. First of all, thew new karma-jasmine relies on jasmine-core code, rather than a local jasmine.js. Sound, but its hard to imagine how to easily make this change. Assuming that all we need to do is to suppress the stack whenever its first line, without the "Error: " is identical to the message, then the following code works:

  function firstLineOfStackWithoutLeadingErrorDifferentFromMessage(){
    var firstLine = stack.substring(0, stack.indexOf('\n') - 1);
    return message && message.indexOf(firstLine.replace(/^Error: */, '')) === -1;
  };

  if (stack && firstLineOfStackWithoutLeadingErrorDifferentFromMessage()) {

and of course this can be refactored to get rid of the duplication of code within the if. Does that seem to be how we should attack this problem? If so, I can submit a pull request.

[wizardwerdna]

There hasn't been much interest in solutions to this problem, although it renders karma-jasmine unworkable for me. Accordingly, since I don't require any Jasmine 2.0 features for my work, I'll just continue to use the 1.5 version of karma-jasmine for now.

[olegskl]

Do we really want to remove the stack trace? I think it's quite useful. I would be interested, however, in the removal of all karma- and jasmine-related fluff from the stack.

[maksimr]

@olegskl no.

Issue about remove 'duplicated' lines:

 Expected '' to be '2'.
 Error: Expected '' to be '2'.

[olegskl]

Oh, okay.

I was thinking that it would be good to have something like:

PhantomJS 1.9.8 (Mac OS X) ngFromHtml() should work for simple dynamic html FAILED
        Expected '' to be '2'.
        at /Users/werdna/wiz-dev-env/test/environment.js:33

instead of:

PhantomJS 1.9.8 (Mac OS X) ngFromHtml() should work for simple dynamic html FAILED
        Expected '' to be '2'.
        Error: Expected '' to be '2'.
            at /Users/werdna/wiz-dev-env/test/environment.js:33
            at /Users/werdna/wiz-dev-env/node_modules/karma-jasmine/lib/boot.js:126
            at /Users/werdna/wiz-dev-env/node_modules/karma-jasmine/lib/adapter.js:171
            at http://localhost:9876/karma.js:189
            at http://localhost:9876/context.html:49

What do you think?

[wizardwerdna]

The long stack trace is of at most modest interest to me, during TDD what I want to know is what errors occurred with a useful error message. I like to use a split window with a relatively small window for the test output. Frankly, the trace information for EVERY expectation renders karma pretty useless to me, particularly as the test scrolls to the bottom of the flow, so I have to scroll up for EVERY red message. This works best for me with my TDD workflow, whether under vi or WebStorm.

I continue to use the 1.X karma because I can't get any value out of the status quo. Of course, when there is no jasmine error message because of a catastrophic crash, a full trace is helpful -- that is what happened in the pre 2.X karma-jasmine.

[maksimr]

fixed in ee4a020

[bstenm]

Hi there, was looking at that thread, is there a good reason to return step.stack rather than step.message? In my case I get a long useless requirejs stack trace following the error message, and I'm guessing the same issue could always occur with other libs used. I suggest that if the irrelevant stack trace is removed anyway why not always return step.message instead of adding new regex tests such as !//(require.js):/.test(entry)

[olegskl]

@bstenm The stack is pretty useful. It would be great though to have a configuration option that would filter out library/framework stack traces.

[bstenm]

agreed that would be the best solution, also with a 'no-stack-trace' one would be good in which case it just returns step.message

[brachycera]

👍 for configuration option on stack traces.
The requireJS stack-trace make error messages difficult to read. Maybe the karma.conf "framework" option could be used to build the "framework filter"?!

[top-master]

This is not fixed yet, at least not correctly.

For example, my context contains JSON, which causes both the error and the JSON to get duplicated in the logs.

expect(window.MyGlobalVariable)
    .withContext('Was not in global var: ' + JSON.stringify(window.jQuery, null, 2))
    .toEqual(jasmine.objectContaining({
        'my/tested/key': jasmine.objectContaining({
            default: jasmine.anything()
        })
    }));

See new ticket: #308