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

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?

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.

Related

Is it bad practice to have a requirejs package with no main script?

Lets say i have a bunch of js view scripts defined as AMD modules in directory 'views'.
Rather than listing them all out in the requirejs config, i could just do this:
require = {
baseUrl: 'js',
packages: [
{ name:'views',location:'app/views' }
...
],
...
}
I then require them as ['views/sunset', 'views/ocean'] (or './ocean' if from another view) etc.
This saves me a whopping 20 seconds or so versus listing them all out individually in the require config, and arguably makes my define() calls more expressive (i.e it's clear which scripts are components, which are utilities etc)
Essentially i'm treating the directory as a package, but there is no main script, so require(['views']) would return a 404. Is there any reason why this approach might be considered bad practice? Are there issues with this that i'm not seeing?
In my previous job we did not have main.js file because each page had different modules so they were loaded dynamically based on the content of the page. I didn't notice any issues with that.
Your solution seems to be similar. If you do not have any errors, it's fine :)
main.js is not required but it is recommended by RequireJS from what I remember

RequireJS Map Configuration of Multiple files

I have some files, like,
test/test1,
test/test2,
test/test3
and i want to rename there path to
newtest/test1,
newtest/test2,
newtest/test3
so that if we try to require the above file, then it will point to new path.
In require, one to one mapping is present, but not sure, if something like this is achievable,
require.map = {
"test/*": "newtest/*",
}
Any help :)
The map configuration option supports mapping module prefixes. Here's an example:
require.config({
map: {
"*": {
"foo": "bar"
}
}
});
define("bar/x", function () {
return "bar/x";
})
require(["foo/x"], console.log);
The last require call that tries to load foo/x will load bar/x.
This is as good as it gets for pattern matching with map. RequireJS does not support putting arbitrary patterns in there. Using "test/*": "newtest/*" would not work. The "*" I used in map is not a pattern. It is a hardcoded value that means "in all modules", and happens to look like a glob pattern. So the map above means "in all modules, when foo is required, load bar instead".
I wonder if you really need map. You can probably just use paths. Quoting from map documentation
This sort of capability is really important for larger projects which
may have two sets of modules that need to use two different versions
of 'foo', but they still need to cooperate with each other.
Also see paths documentation
Using the above sample config, "some/module"'s script tag will be
src="/another/path/some/v1.0/module.js".
Here is how paths can be used to map the directory from test to newtest for your example
paths: {
"test": "newtest"
}

DRY Testing in Node.js

I've written a Node.js CLI and would like further development to proceed in a TDD style. I have an ideal workflow in mind and want to know if it is possible with existing frameworks.
When I write a new function, I'd like to document its preconditions in an assertion that will throw an error if e.g. input doesn't validate.
Postconditions should be specified in or near the function
The pre and postconditions should generate tests to be run with npm test
Assertions should only be checked in development mode
Documentation in each function should generate (html|md) documentation for the CLI
If I want to add tests other than precondition / postcondition / invariant tests it should be easy to do so
When mocking tests, there should be a way to specify "the universe before" and "the universe after". For instance to test a command that scaffolds a new project a-la express, I should be able to specify the initial directory structure as empty ({}) and the final directory structure as a JSON object representing the result ({ name: "project", path: "/project", type: "directory", children: { ... } }) <-- or something like that. This seems to require the ability to intercept writes to the file system.
I don't have a candidate library for automated test generation yet. I think a mix of Mocha, rewire and Contractual / Obligations might work for everything else, but I'm interested to hear about other approaches.

Intern: DRY Runners for multiple project in one workspace

While realizing that my project setup might be the root cause of my problem, here's what I'd like some help with (moving from another framework to Intern):
I've different (>20) projects in one dev workspace, so I've (>20) different directories with test code. I'd like a project to be testable on itself, but also would like to execute all suites together.
I am specifying to use RequireJS as an AMD loader and where my tests can be found per project (one for nodeJS, one for browsers) through a config file. PLUS I have one overall config file specifying all the files.
You can image there is quite the duplication, what would be a good approach to DRY this up?
Note: it would also be welcome to help to describe my problem better (more generic or less TLDR)!
Since Intern configuration files are just AMD modules you can use the normal dependency loading mechanism to load and combine configuration data from multiple files:
// in your “do everything” master configuration
define([
'projectA/tests/intern',
'projectB/tests/intern',
'projectC/tests/intern',
// …
], function () {
var configs = Array.prototype.slice.call(arguments, 0);
function getCombined(key) {
return Array.prototype.concat.apply([], configs.map(function (config) {
return config[key];
}));
}
return {
suites: getCombined('suites'),
functionalSuites: getCombined('functionalSuites'),
// …
};
});

How to test a Grunt task? Understanding and best practices

I'm a bit stuck with understanding how to write complicated Gruntfile.js and use it with tests. Am I using Grunt in a right way? I would like to ask community for help and contribute in an other way.
I'm writing a new task for Grunt and want to roll it out for wide audience on Github and npm. I want to make automated testing for this task (and I want to learn how to do it properly!).
I want to test different options combinations (about 15 by now). So, I should multiple times:
run cleanup
run my task with next options set
run tests and pass options object to the test
Some non-working code to look at for better understanding:
Gruntfile:
grunt.initConfig({
test_my_task: {
testBasic: {
options: {
//first set
}
},
testIgnore: {
options: {
//another set
}
},
//...
}
clean: {
tests: ['tmp'] // mmm... clean test directory
},
// mmm... unit tests.
nodeunit: {
tests: ['test/*.js'] //tests code is in 'tests/' dir
}
});
grunt.registerTask('test', ['test_my_task']);
I know how to check if tmp/ folder is in desired state when options object given.
The problem is putting things together.
I would ask just for template code as an answer, npo need to put working example.
PS: you can propose another testing tool, nodeunit is not a must.
PPS: crap, I could have written this in plain javascript by now! Maybe I'm doing wrong that I want to put Grunt into the unit tests? But I want to test how my task works in real environment with different options passed from Grunt...
You might want to have a look at the grunt-lintspaces configuration. The tests look like this, and it seems like a good way to do it. grunt-lintspaces uses nodeunit but a lot of plugins these days seem to.
If you don't want to test actual grunt output and instead functionality, you could use grunt-mocha-test - https://github.com/pghalliday/grunt-mocha-test which I am using for the grunt-available-tasks tests. I prefer the describe style of testing personally, it reads very well; the advantage of using this is that you actually test what your plugin does without including a ton of config in your Gruntfile; i.e. test code should be in the tests.
Grunt is well tested already so it doesn't make sense to test that its configuration works. Just test the functionality of your own plugin.

Resources