Use the new message passing system in grunt-contrib-jasmine

[jabbany]

This PR addresses #63 (I think)

Do not merge this PR until the corresponding PR in gruntjs/grunt-contrib-jasmine#302 is merged and released onto npm. (Update: Upstream has been merged and AFAIK is available in an npm released version. Still possibly blocking on gruntjs/grunt-contrib-jasmine#300)

This PR contains changes that will mesh with the new message passing system if it is introduced in grunt-contrib-jasmine.

Bugs:

• Right now doing grunt test fails on "nodeunit:outfile" - shouldWriteCoverage, but manually running the single test grunt test:outfile produces no errors. My suspicion is that this is caused by subsequent tasks in multi task don't run their specs gruntjs/grunt-contrib-jasmine#299 and will be patched with moved resolveJasmine/jasminePromise function to fix scope issue gruntjs/grunt-contrib-jasmine#300 but will need further testing.
• Version numbers need to be bumped again when the patches on grunt-contrib-jasmine are released
• The istanbul package has been deprecated and this project may eventually need to move to the suggested nyc package.

[jabbany]

PR on the other side has been merged.
Still pending new version in grunt-contrib-jasmine.

[pigranada]

Hi.

When will this be merged? =grunt-contrib-jasmine has released the version v.2.1.3 for update in Puppeteer.

Thanks

[jabbany]

This patch should be very simple to review, but some tests fail right now (somehow certain tests are skipped only when running all tests) which is suspected to be related to gruntjs/grunt-contrib-jasmine#300 but since that hasn't been merged or closed, I can't test if that actually fixes things.

In the long run though this repo needs major refactoring (or it needs to be deprecated/archived) since the istanbul package has been deprecated in favor of nyc which features major API changes. It is not clear whether this module makes sense in the current grunt testing ecosystem.

[maenu]

I merged with some additional version adjustments, including a bump. But I am hesitant to publish before all tests pass, i.e. the issues with the failing tests of 'test:outfile', 'test:threshold' when used in sequence with other tests.

In any case, as @jabbany mentioned, nyc should be used instead of the deprecated istanbul. Now I am wondering: The purpose of this project was to run client-side Jasmine tests in a browser environment integrated in the CI and collect coverage information. Maybe we should reevaluate a few things. I am not currently active in JS, but here is my opinion:

• Is grunt still the way for JS CI? For me yes, many people are using it, it is stable, even jQuery uses it (https://github.com/jquery/jquery/blob/master/Gruntfile.js), so I would argue grunt is here to stay for a while.
• Is grunt-contrib-jasmine the way to go for Jasmine browser tests? I think so, they moved from the deprecated PhantomJS to the Google-backed pupeteer, which also seems to be here to stay.
• Is istanbul the way to collect coverage information? Not any more, nyc replaced it and deprecated istanbul.

So, judging from the name of this repo, as it includes istanbul, I think it would be best to create a new repo for using nyc. I have no experience with nyc, but I guess a lot of this project could be reused. I would like to wait until gruntjs/grunt-contrib-jasmine#300 is merged and published, so we could test against it. If that works, I will publish a new version, so that we have a working solution for an istanbul setup.

@jabbany As you seem to be active in this domain, what do you think?

[jabbany]

Actually, I'm not particularly active in JS testing frameworks... I just happen to have a project from years ago that depended on this module to do coverage testing. The move to Puppeteer in grunt-contrib-jasmine kind of borked the coverage part of my CI tests so I've been making sparse PRs across the projects to try and get the old toolchain working again.

At this point though, it might not make sense to go with this kind of toolchain, given that nyc is itself a CLI test+coverage tool. The alternative is to make the coverage first-class, so instead of grunt-contrib-jasmine (unit testing) + grunt-template-jasmine-istanbul (special template to generate coverage), the workflow would be grunt-simple-nyc (seems to be the more maintained grunt+nyc modules) + ??? (unit testing framework).

[pigranada]

It seems that grunt-template-jasmine-istanbul is already a deprecated project. I will be looking to grunt-simple-nyc if it will fit as a solution for our Jasmine test automation or maybe we can fully move to nyc.

Thank you so much for your inputs and suggestion. Really appreciate it.