Jasmine example shows no cli output

[davemckenna01]

I followed everything here in the README of this repo, but I get no output on the cli when I run jasmine. I must be missing something obvious.

which jasmine shows ./node_modules/.bin/jasmine which is in my project dir.

I run with explicit locations and get the same result: JASMINE_CONFIG_PATH=spec/support/jasmine.json jasmine spec/jasmine_examples/PlayerSpec.js

By no output I mean:
prompt>$jasmine
prompt>$

Any ideas?

[davemckenna01]

On further investigation, it looks like I need to specify a reporter. Well an exit code reporter seems to be default and bash $? tells me what the exit code is.

Might it be worth mentioning this in the README/docs? I feel like people might expect to see command line output when they're getting started running the example tests.

[davemckenna01]

Does jasmine ship with a terminal reporter?

[kaicataldo]

Was seeing results until the latest version. Now doesn't report anything. Rolling back to 2.4.1 reports results as expected.

Looking around and not seeing how I add a custom reporter either as a CLI flag or in the jasmine.json file. Any help would be appreciated!

[amavisca]

Hmm, not exactly sure why this is happening off the top of my head. Looks like a provideFallbackReporter was added to jasmine-core's env interface which we just call through to. It might be good to look there.

Ultimately it shows up here: https://github.com/jasmine/jasmine/blob/master/src/core/ReportDispatcher.js

If this dispatch happens after we call execute, then we'll have already added the exitCodeReporter so it won't add our console reporter. Not sure if that's the case though.

[flore77]

I have also a similar problem and I think this is because now in the 2.5.0 version, the configureDefaultReporter is always called and defaultReporterAdded will always be true and will enter this branch exiting the process.

The defaultReporterAdded prop should not be set always to true, because now only jasmine-core knows if any reporter has been added and if the default reporter should be used, https://github.com/jasmine/jasmine/blob/c7cc3b4a29e92bf59fe56d5a8982e87b58c5c1d7/src/core/ReportDispatcher.js#L30.

[agirorn]

Is there a workaround for this bug until a new jasmine is published?

[agirorn]

This is still broken for everyone that has "jasmine": "^2.4.1" and "jasmine": "^2" in there package.json, They will get 2.5.0 on next fresh npm install and experience this issue. Are you going to publish 2.5.1 with this fix ?

[slackersoft]

Fix should be released in 2.5.1

[bcaudan]

As explained in #90, it still does not work with 2.5.1.

[Liero]

yes, still does not work in 2.5.1. Please reopen, otherwise new issues will be reported

[flore77]

Hey,

The fix that I applied for this issue, unfortunately, does not work for the defaultReporter. It is working for third-parties reporter, it was the same problem like in #43.

How @bcaudan pointed out in #90 the problem is:

It seems that the console reporter is not used because it is only provided as a fallback reporter. However, there is always another reporter provided, the exitCodeReporter.

[nashwaan]

Jasmine cli does not hang in v2.5.1 as it used to be in v2.5.0, but still no jasmine report output in the command line in v2.5.1.

@slackersoft Could you explain how to get the console reporter to work as it used to be in v2.4.1?

If this is dropped in favor of 'exitCodeReporter', then how to get the 'consoleReporter' working again???
Sample code, please?

[em0ney]

I'm moving back to version 2.4.1 until this is resolved

"jasmine": "~2.4.1",

[unconed]

For a quick solution, you can drop in a spec/helpers/consolereporter.js to get output back:

var util = require('util');
var options = {
    showColors: true,
    print: function() {
        process.stdout.write(util.format.apply(this, arguments));
    }
};

jasmine.getEnv().addReporter(new jasmine.ConsoleReporter(options));

Moral of the story: if you have pluggable output modules, be nice and warn if there's no output hooked up at all, before people waste an hour or two each debugging mysteries.

[peterhal]

I just got bit by this. This issue is still breaking everyone with

jasmine: "^2.4.1"

In their package.json.

[nashwaan]

Thanks alot @unconed. Your solution works!
I don't know where you got this, but I think this need to be mentioned in the docs by the jasmine-npm team. People should not be expected to find this solution in the issues section of the github project.

Now I get this output:

ConsoleReporter is deprecated and will be removed in a future version. Started
....................
20 specs, 0 failures
Finished in 0 seconds

But notice the first line says ConsoleReporter will be removed. What are the alternatives in order to avoid this functionality to be broken in the future?

[slackersoft]

It sounds like this wasn't actually fixed as I thought it was with the 2.5.1 release. Hopefully, I should have some time today to take a look at it and see what the problem is.

The intent of the reporter changes was to remove the need for a custom reporter to have to tell Jasmine about full success/fail of the test run and just print the output that it wants.

[m-a-r-c-e-l-i-n-o]

@slackersoft and people of this thread. Here's some light at the end of the tunnel: jasmine/jasmine#1208
My jasmine knowledge is fairly limited, but I was itching to get this moving along, hopefully it helps.
EDIT: False alarm, guys.

[slackersoft]

Alrighty, I think I know what happened here and what the problem is, and I have a workaround for now and some options I'm mulling over for real fixes.

First, why this is happening:

1. Jasmine-npm provides its ConsoleReporter to jasmine-core as a fallback reporter to be used if no other reporters are added
   1. This should then allow users to specify custom reporters directly to the jasmine-core environment without having to use the addReporter function in jasmine-npm
2. Just before starting execution, jasmine-npm add its ExitCodeReporter to the jasmine-core environment
3. When jasmine-core starts reporting, it sees that it has a reporter (ExitCode) and doesn't use the fallback reporter provided.

If you want to keep use the most current ConsoleReporter you should use the one provided in this package. It should be exported on the main jasmine object as ConsoleReporter. Something like this:

var jasmineNpm = require('jasmine');
jasmine.getEnv().addReporter(new jasmineNpm.ConsoleReporter(...));

The two primary options I'm thinking of for long-term solutions are:

1. Plum a way for the ExitCodeReporter to be added to jasmine-core such that it doesn't count against the fallback reporter
2. Allow libraries to check if a jasmine-core environment has any reporters registered, so jasmine-npm can only add ConsoleReporter if there aren't any other reporters.

I would love to hear any thoughts on these solutions or any suggestions for another way to solve this.

Thanks for your patience, and sorry for the premature closing earlier.

[m-a-r-c-e-l-i-n-o]

@slackersoft In your first solution, would the jasmine-core be aware of the actual ExitCodeReporter reporter? Or do you plan to pass in an "offset" flag (i.e. addReporter(ExitCodeReporter, 'dont-count-me') -- essentially telling it not to count "whatever" this reporter is)? If the latter, I would say it sounds like a winner.

The second solution also sounds appealing to me, in that it's non intrusive and that it might actually be useful for my test runner, but could be misleading if the reported count is not requested immediately before the execution. So maybe it would be worth it to make this very clear in the docs, or designate a flag in the addReporter method (i.e. addReporter(ConsoleReporter, 'final')), which causes jasmine-core to throw an error if any other reporters are added after this "final" reporter is added. Or maybe you could do it with callbacks -- one that supplies the reporter count, allowing jasmine-npm to activate both the ExitCodeReporter and ConsoleReporter if the count is zero, or just ExitCodeReporter otherwise, and encourage users to only use this for non-conflicting reporters, since all calls would receive the same count.

[slackersoft]

Due to the direction of the dependency chain, it would be hard to sensibly allow jasmine-core to know specifically about the ExitCodeReporter from jasmine-npm, so it would likely be some kind of flag to tell jasmine-core to ignore this reporter when checking if any have been registered before adding the fallback.

The second option probably wouldn't include any way to fail if a reporter was added after another given reporter, so it would just be up to jasmine-npm to add ConsoleReporter just before starting the run if no other reporters are registered.

I'm leaning toward the second option because it is a bit less involved, but it also seems to remove the need for a fallback reporter at all...

[th317erd]

It seems to me like this is kind of backwards to begin with. Shouldn't jasmine-core contain and use the ExitCodeReporter by default if no other reporter exists, and jasmine-npm can set the ConsoleReporter?

[slackersoft]

Jasmine-npm is the only Jasmine runner that I know of that it makes sense to have a direct exit code produced from the run. Most other runners for Jasmine are intended for use in the browser where having an exit code is nonsensical.

[th317erd]

So instead of setting the ConsoleReporter as a FALLBACK in jasmine-npm why don't you just set both reporters?

addReporter(new ConsoleReporter(...))
addReporter(new ExitCodeReporter(...))

[m-a-r-c-e-l-i-n-o]

@th317erd Causing conflicts with other reporters would be one reason not to do that.

[slackersoft]

@th317erd because if jasmine-npm always registers its ConsoleReporter it is impossible for users of jasmine-npm to not include it when they want to customize the output. This is sort of the root cause of the genesis of this problem.

[bcaudan]

I proposed another way to solve this with #92.

It seems a bit odd to handle exit code with a reporter but it was working for now. With a way to handle an env execution callback in jasmine, then ExitCodeReporter could be replaced by a jasmine-npm default onComplete callback. This callback could be overriden by the existing onComplete option.

Then jasmine-npm would only provide the console reporter as a fallback reporter.

maybe I am missing something, what do you think of this strategy?

[m-a-r-c-e-l-i-n-o]

@slackersoft
Interesting approach, really gets at the heart of the problem -- giving the user choice :)
Thank you.

[nashwaan]

Thanks @slackersoft
The problem is now solved in v2.5.2