How do you specify test suites in Intern using a wildcard?

北城余情 提交于 2019-12-06 11:28:26

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.

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.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!