How do you specify test suites in Intern using a w

问题:

I have a bunch of unit tests in this folder: src/app/tests/. Do I have to list them individually in intern.js or is there a way to use a wildcard? I've tried

suites: [ 'src/app/tests/*' ]

but that just causes the test runner to try to load src/app/tests/*.js. Do I really have to list each test suite individually?

回答1:

The common convention is to have an all module which collects your test modules, e.g.:

define([
    './module1',
    './module2',
    // ...
], function(){});

Then you simply list the all module in the suites array, like this:

suites: [ 'src/app/tests/all' ],

Generally this is no different from the standard practice with DOH in Dojo 1.x either, other than being under a different module name. AMD loaders do not support globbing in module IDs, so this isn't really a direct limitation of Intern.

It may seem onerous, but ordinarily you would add each module to all.js as you create it, so it's not really that much additional work.

回答2:

I agree that the verbosity and inflexibility of this configuration is annoying and hard to scale.

While it's not the same as a wildcard, here is how I solve that problem.

Modified intern.js config file:

define(
    [   // dependencies...
        'test/all'
    ],
    function (testSuites) {
          suites: testSuites.unit,
          functionalSuites: testSuites.functional,
    }
)

The power in this comes from the fact that the test/all module can return whatever it wants to. Simply give it some nicely named properties which are arrays of module ID strings and you are ready to rock.

Specifying test modules in the define() dependency array of a module given to suites or functionalSuites does work. But that is not very flexible. It still requires you to cherry-pick test suites and be careful about commas and which ones are commented out, etc. What you really want are named collections that can be exported. I do that like so...

test/all:

define(
    [   // dependencies...
        './unitsuitelist'  // array of paths, generated by hand or Grunt, etc.
        './funcsuitelist'
    ],
    function (unitSuites, funcSuites) {

        var experiments,
            funTests,
            usefulTests,
            oldTests

        // any logic you want to construct great collections of test suites...

        myFavoriteUnitSuites = funTests.concat(experiments);
        myFavoriteFunctionalSuites = usefulTests.concat(oldTests);

        return {
            unit: myFavoriteUnitSuites
            functional: myFavoriteFuncSuites
        }
    }
)

Just make the necessary logic one time with a few reasonable collections. Then swap them out in the returned object during development. And if you prefer to change lists of module IDs instead of code, this pattern can still help you. It's easy to auto-generate a list of all test suite file locations within their directories using bash, Grunt, or other tools. This can be automatically fed into the intern.js configuration file with a similar pattern to the one above. Just remove the logic and it can effectively be a wildcard. If each category of test suite (unit and functional) lives in its own directory, it is very easy to generate path lists of all files contained within them.