So, duplicate error messages about karma-jasmine HOT 14 CLOSED

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

from karma-jasmine.

@wizardwerdna hi!

I think it because [email protected] change error message format:

You can try fix it here

Thanks!

from karma-jasmine.

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?

from karma-jasmine.

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.

from karma-jasmine.

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.

from karma-jasmine.

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.

from karma-jasmine.

@olegskl no.

Issue about remove 'duplicated' lines:

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

from karma-jasmine.

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?

from karma-jasmine.

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.

from karma-jasmine.

fixed in ee4a020

from karma-jasmine.

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)

from karma-jasmine.

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

from karma-jasmine.

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

from karma-jasmine.

👍 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"?!

from karma-jasmine.