Added option.keepAlive

[nrako]

If set to true jasmine async task stay alive even after a test failed.

[inossidabile]

👍

[jsoverson]

Working on pushing a new version today, what would the purpose of this be? @inossidabile, maybe you can answer since you +1 more recently.

[inossidabile]

@jsoverson to make it run all tests (separated to several tasks) even if one of them failed in the beginning. Depending on the organization of your specs it could really be helpful.

[nrako]

Let me tell you my purpose, I use grunt.event.on('watch', to watch changed files and run tests that are relevant for them, so my tests are done blazingly fast and continuously. keepAlive allows me to do continuous testing by only watching the notifications after saving the file I'm working on. Of course without this, I would have to relaunch the grunt task each times a test fail.

[jsoverson]

@nrako, how to you rerun the tests? In the browser, or in phantom? If in phantom, how is that re-running automated? I'd love to know more and see if this usage can be better supported at the core.

[nrako]

@jsoverson I don't use this setup anymore, and I'm not that fond of my implementation. But it's quite simple, this is how I did it.

I defined a task which is in charge of running jasmine on modified files. And a watch task to run that task.

grunt.registerTask('blazingfastjasmine', 'Run jasmine for modified files only', function() {
    // ... with some dummy convention define which specs should be run for each modified file (for modified spec files it's more easy) (the part that I'm not fond of...)
    grunt.config.data.jasmine.src = src;
    grunt.config.data.jasmine.options.specs = specs;
    grunt.task.run('jasmine');
});

  watch: {
      scripts: {
        options: {
          nospawn: true
        },
        files: ['app/**/*.js', 'test/jasmine/**/*.js'],
        tasks: ['blazingfastjasmine']
      }
    },

To get the modified files :

  // Listen for events when files are modified
  grunt.event.on('watch', function(action, filepath) {
    changedFiles[filepath] = action;
  });

I don't understand why this problem isn't taken more seriously, having to run all tests manually or each time a single file change is nasty. The Guard community seems to do it a tad better in that area e.g. netzpirat/guard-jasmine or kanzeon/guard-mocha-node.

However what I've seen so far rely on convention and regex. I don't like it! It should be smarter! For example by using an history of stacktraces for each spec to determine which spec to run when a specific file is modified. An engineered solution which doesn't enforce any convention must be possible right?

What is your thoughts? Maybe I missed something, anyone?

[vladikoff]

@jsoverson @nrako what should we do regarding this PR?

[nrako]

I'm closing it, I don't use it anymore and it seems I was alone...