server task

[laurelnaiad]

Hi @geekdave,

Well I started to work on a tests platform and quickly went "off course". Specifically, I started to notice that I was going to be implementing something that wanted to easily switch the configuration of the server that serves the test html in order to give the plugin a workout.

Having an easily modified (from grunt) server for tests was also something that I needed for my own stuff -- because I wanted to be able to control which files are tested and which tests are run and stuff like that.

I also harkened back to the part where I was trying to set up mocha and chai and the reporter and remembered that it felt like more of a hurdle to do that than it was to install the grunt-blanket-mocha plugin.

So.... I've implemented a blanket_mocha_server task. Basically its goal is to bundle mocha.js, mocha.css, blanket.js and chai.js, and to let you specify the system under test files and test files and go. It's quite configurable but if you do nothing special you get a runner that supports chai's should and expect. Here's a simple sample configuration:

  grunt.loadNpmTasks('grunt-blanket-mocha');
  grunt.loadNpmTasks('grunt-blanket-mocha-server');
  grunt.loadNpmTasks('grunt-contrib-watch');

  grunt.registerTask('test', ['blanket_mocha_server', 'blanket_mocha', 'watch']);

  grunt.initConfig({
    blanket_mocha_server: {

      server: {
        options: {
          port: 3001,
          testConfig: {
            htmlFile: './test/test-runner.html',
            blanketOptions: {
              'data-cover-only': '//funcs/',
            },
            sutFiles: [
              '/funcs1.js',
              '/funcs2.js'
            ],
            testFiles: [
              '/tests.js'
            ],
          }
        }
      }
    },

    blanket_mocha: {

      unit: {
        options: {
          urls: [ 'http://localhost:3001/test/test-runner.html' ],
          reporter: 'Nyan',
          threshold: 80,
          moduleThreshold: 80
        }
      }
    },

    watch: {
    }

  });

And here are the (overrideable) default options (as in, you don't need to use chai and you can replace the files that are served to your hearts content, etc.):

      var defaultOptions = {
        testConfig: {
          htmlFile:               null,
          sutFiles:               null,
          testFiles:              null,
          blanketOptions:         null,
          blanketPhantomOptions:  null,
          mochaPath:              '/node_modules/grunt-blanket-mocha-server/tasks/lib/mocha.js',
          mochaCssPath:           '/node_modules/grunt-blanket-mocha-server/tasks/lib/mocha.css',
          mochaSetupScript:       'mocha.setup(\'bdd\');',
          blanketPath:            '/node_modules/grunt-blanket-mocha-server/tasks/lib/blanket.js',
          gruntReporterPath:      '/node_modules/grunt-blanket-mocha/support/grunt-reporter.js',
          mochaBlanketPath:       '/node_modules/grunt-blanket-mocha/support/mocha-blanket.js',
          assertionLibs:          ['/node_modules/grunt-blanket-mocha-server/tasks/lib/chai.js'],
          assertionsSetupScript:  'window.expect = chai.expect; var should = chai.should();',
          runnerTemplate:         './node_modules/grunt-blanket-mocha-server/tasks/lib/test-runner-template.html'
        }
      };

So my question to you is: do you have an interest in bundling this task with your plugin? If so, I can bundle it up in a fork of grunt-blanket-mocha.

Alternatively I can publish it as its own plugin (which is how it's currently configured) -- in which case, do you have a problem with making it a dev dependency and using it in the test suite that I promised to take a stab at?

Either way, I'm certainly open to discussing changes after you've had a chance to see the code.

Please let me know which way you're leaning (no commitments) so I can post it to github in a way that makes sense. Obviously the paths to the files would change if the task is going to live in your plugin.

[laurelnaiad]

(I forgot to mention --- the configuration above is the entire test config -- you don't write your own html file -- it's generated for you as the file specified by the htmlFile parameter)

[geekdave]

Hey @stu-salsbury ... sorry for the delay. Was on vacation.

I like the idea of having a configurable test runner to make sure the plugin does all of its jobs no matter what the environment looks like. Do you mean that the test runner HTML file would actually be generated server-side based on those config-options? If so I wonder if using Grunt's templating engine might be a better fit for this.

The BlanketJS tests themselves make heavy use of templating to test various permutations of configuration. Not saying that the server solution is wrong... just that it seems a bit heavy and maybe a lighter solution exists.

Since you've already started this as a separate plugin, let's keep going with that option for now. I'd love to see it in action whenever you've got something to share. Then if it makes sense to refactor and merge it here, we can go that route.

Thanks for your time and thoughts! Looking forward to collaborating.

[laurelnaiad]

Funny you should mention the blanket tests -- I worked with them a little in the context of some blanket and grunt-blanket changes that I've been working on, too -- some of which have parallels in the PRs that I'm hoping to send your way once we get a couple of tests into a test suite.

Rest assured my server task makes use of templating to build the html that it serves -- those defaults for the parameters that I copied into my comment above become the fodder for the template :) If you go with the defaults, you just need to configure these when using the server task:

          htmlFile:               'test/test-runner.html', // this is the file generated by the task to serve up the tests the
          sutFiles:               ['src/**/*.js'], // test all js files below src
          testFiles:              ['test/unit-tests/**/*.js'], // run all of the tests defined below test/unit-tests

The rest of those options can be overriden if, say, you want to use expect.js instead of chai (as I do so I can test IE8), or if you want to use a template other than the one that will come baked-in.

I'll get it posted on github right quick so you can see what I'm talking about -- it's really just a way of using templating to serve the tests through configuration so they can be more easily served and/or so that you can programmatically control what you're serving (useful in my "seed" thingy and also probably in testing grunt-blanket-mocha). Aside from that it just runs grunt-contrib-connect after it constructs the html. It won't necessarily fill every need, but since the template that the task uses is itself is overrideable, I hope it might fit into a good many scenarios.

[geekdave]

Sounds great. Looking forward to seeing this in action!

On Thu, Sep 19, 2013 at 4:34 PM, Stu Salsbury notifications@github.comwrote:

Funny you should mention the blanket tests -- I worked with them a little in the context of some blanket and grunt-blanket changes that I've been working on, too -- some of which have parallels in the PRs that I'm hoping to send your way once we get a couple of tests into a test suite.

Rest assured my server task makes use of templating to build the html that it serves -- those defaults for the parameters that I copied into my comment above become the fodder for the template :) If you go with the defaults, you just need to configure these when using the server task:

      htmlFile:               'test/test-runner.html', // this is the file generated by the task to serve up the tests the
      sutFiles:               ['src/**/*.js'], // test all js files below src
      testFiles:              ['test/unit-tests/**/*.js'], // run all of the tests defined below test/unit-tests

The rest of those options can be overriden if, say, you want to use expect.js instead of chai (as I do so I can test IE8), or if you want to use a template other than the one that will come baked-in.

I'll get it posted on github right quick so you can see what I'm talking about -- it's really just a way of using templating to serve the tests through configuration so they can be more easily served and/or so that you can programmatically control what you're serving (useful in my "seed" thingy and also probably in testing grunt-blanket-mocha). Aside from that it just runs grunt-contrib-connect after it constructs the html. It won't necessarily fill every need, but since the template that the task uses is itself is overrideable, I hope it might fit into a good many scenarios.

— Reply to this email directly or view it on GitHubhttps://github.com/ModelN/grunt-blanket-mocha/issues/6#issuecomment-24778488 .

[laurelnaiad]

I posted something that works. I haven't finished the documentation yet, and as yet I haven't done a (real) test suite. I'm hung up on some other things right now, but just wanted to let you know it's out there:

https://github.com/stu-salsbury/grunt-blanket-mocha-server

[geekdave]

@stu-salsbury : Brilliant! Looks like a great start. I like the way you described the commonalities and differences between our two projects. Makes me think that these projects could indeed be complementary without needing to be rolled into the same repo. On that note, I think I can close this issue now.

Looking forward to taking this for a test-drive soon. Please do keep me in the loop as the project progresses.