# Features

munit is based on a module of tests system. The approach being that each module focuses on a single function/flow,
and each assertion in that module is intended to test each path of the function/flow.


### Assert

Each module gets passed it's assert object for running tests. munit is different in it's approach to running tests,
in that every test is required to have a name/message assigned to it. This allows every individual test to be tracked.

```js
munit( 'module', function( assert ) {
	assert.pass( 'test message' );
});
```


### Module Tree

Modules are referenced from a tree structure, where submodule inherits options from parent modules.

```js
munit({
	core: function( assert ){},
	'core.read': function( assert ){},
	'core.util': function( assert ){},
	'core.util.isArray': function( assert ){},
	'core.util.isFunction': function( assert ){},
	'core.render': function( assert ){},
	'core.render.path': function( assert ){},
	'core.render.flush': function( assert ){},
});

/*
	The above would result in the following structure

	core
	|-read
	|-util
	  |-isArray
	  |-isFunction
	|-render
	  |-push
	  |-flush
*/
```


### Spies

Spies give access to control code flow of functions. It allows synchronous testing on asynchronous code,
while still controlling output.

```js
munit( 'test', function( assert ) {
	var object = { prop: munit.noop },
		spy = assert.spy( object, 'prop' );

	object.prop === spy; // true
});
```


### Priority

munit allows modules to have a higher priority run time than other modules. So lower level tests can be triggered first
to ensure the base still works properly, then the higher level tests can be run. When setup correctly, this can
reduce the amount of time spent debugging a failed test if it occured in a utility type function.  
  
*Note*: This only ensure trigger order, async tests will still be run in parallel. Use dependencies to handle async order.

```js
munit( 'test-util', { priority: munit.PRIORITY_HIGH }, function( assert ) {
	assert.equal();
});
```


### Queueing

Module queueing is an option for when there is a limited amount of resources to test with. One example would be locally
testing a servers endpoints. For a good test, there should be only 1 request hitting the API at a time, which means
there is only 1 port resource availiable for use.

```js
munit.queue.add({ port: 8001 });
munit.queue( 'test-server', { expect: 5 }, function( queue, assert ) {
	var port = queue.port;
	// Run async tests against port
});
```


### Dependencies

Module dependency is a feature that allows modules to not be triggered until another module has completed it's tests.

```js
// test-A simply writes contents to a file
munit( 'test-A', 1, function( assert ) {
	fs.writeFile( '/tmp.js', "BLAH BLAH BLAH", function( e ) {
		if ( e ) {
			assert.error( 'failed write', e );
		}
		else {
			assert.pass( 'wrote successfully' );
		}
	});
});

// test-B wont be triggered until after test-A has written to the file '/tmp.js'
munit( 'test-B', { depends: 'test-A', expect: 1 }, function( assert ) {
	fs.readFile( '/tmp.js', function( e, contents ) {
		assert.ok( 'found blah', contents && contents.indexOf( ' BLAH ' ) >= -1 );
	});
});
```


### Focused Tests

The Cli script has an option that will only run the specified namespace. This is helpful during development of larger projects
when the changes made don't require the full test suite.

```js
munit({
	'core': function(){},
	'core.util': function(){},
	'core.network': function(){},
	'core.model': function(){},
});
```

```
-- Only runs the core.network assertions module
$ munit /path/to/test/dir -f core.network
```