Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-expose detailed spec result information to reporters #547

Closed
alextreppass opened this issue Mar 11, 2014 · 7 comments
Closed

Re-expose detailed spec result information to reporters #547

alextreppass opened this issue Mar 11, 2014 · 7 comments

Comments

@alextreppass
Copy link
Contributor

Hi, I'm looking at moving a test suite to Jasmine 2.0.0 and have it running fine locally, however running it remotely on Saucelabs depends on programmatic access via a custom reporter, namely: jasmine-jsreporter.

In Jasmine 1.3.1, specs used to expose the following information to reporters:

  • durationSec
  • totalCount
  • passedCount
  • failedCount

@sclevine has done some work to port jasmine-jsreporter in jasmine-jsreporter/pull/7 but it seems the above information is no-longer available to reporters in Jasmine 2.0.0.

Would it be possible to get the above back into Jasmine 2?

@sclevine
Copy link

More specifically, Jasmine 2 only seems to count failed expectations:

  Spec.prototype.addExpectationResult = function(passed, data) {
    if (passed) {
      return;
    }
    this.result.failedExpectations.push(this.expectationResultFactory(data));
  };

If it counted total number of expectations (or failed passed expectations) we would have enough information.

Duration is actually exposed by Jasmine, and does work for me with jasmine-jsreporter/pull/7.

@alextreppass
Copy link
Contributor Author

Duration not appearing for us may be due to how we're using grunt-saucelabs. Good to hear it should be working.

@infews
Copy link
Contributor

infews commented Mar 11, 2014

Take a look at the source for the HtmlReporter.

We made a decision to pull out the counts and duration from core and make them a Reporter concern. So Jasmine just tells the Reporters what the results were, anything else has to be built in a reporter. One could imagine different ways to refactor this, but we like the separation of this functionality out of core.

@alextreppass I would expect the reporter for sauce to be able to do the same as the HtmlReporter to return this functionality.

@sclevine
Copy link

The reporter interface doesn't seem to expose the total number of expectations (per spec) or the number of expectations that passed. For example, in the HtmlReporter only the failed expectations are considered:

for (var i = 0; i < result.failedExpectations.length; i++) {
   var expectation = result.failedExpectations[i];
   messages.appendChild(createDom('div', {className: 'result-message'}, expectation.message));
   messages.appendChild(createDom('div', {className: 'stack-trace'}, expectation.stack));
}

Also, I attempted to stay within the reporter interface for my Jasmine 2 port of jasmine-jsreporter, but (as far as I can tell) it loses information about the nesting of the test suite. So I ended up traversing jasmine.getEnv().topSuite().

@alextreppass
Copy link
Contributor Author

I'm digging into this again, and have started to re-write the old JSReporter under the new event-driven style shown in jasmine 2's HTMLReporter.

@alextreppass
Copy link
Contributor Author

Ok I've got pretty far, duration and things are working as expected, and I'm building the report as events come in: https://github.com/alextreppass/jasmine-jsreporter/blob/jasmine-2.0/jasmine-jsreporter.js

As @sclevine points out, the only thing we're missing is information on the spec object given to specDone() which details the total number of expectations.

Can this be added? I don't really want to have to dig into jasmine getEnv() internals.

@infews
Copy link
Contributor

infews commented Jun 23, 2014

It's low priority for us to add expectation count back in. This - to my knowledge - is the only request we've seen for it.

That said, we'd be happy to look at a pull request that implements this functionality. Closing.

@infews infews closed this as completed Jun 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants