Directory Structure Examples

When creating tests for an application, as opposed to developing tests for a reusable component library like Dojo, we recommend placing the tests in a location that is outside of the normal source code tree rather than inside the code package directory. Doing so provides the following benefits:

1. Production deployments are simplified by eliminating the need to exclude tests during the build process.
2. The risk of accidental disclosure of security-sensitive information stored inside test files is eliminated, as data related to testing is never part of the directory structure that is exposed by production Web servers.

The tests directory should ideally be subdivided into three to four subdirectories:

• functional: Functional test modules
• support: Testing support files: utility modules, mock data, custom reporters, custom interfaces, etc.
• system (optional): A separate set of system integration tests that do not correspond directly to individual application modules
• unit: Unit test modules

The directory structure within the functional and unit tests directories should match the directory structure of the main application package so that it is easy to associate tests with their corresponding source code. Following these rules, a recommended directory structure might look like this:

/yourProject
	src/
		app/
			widgets/
				foo.js
		index.html
	tests/
		functional/
			widgets/
				foo.js
		support/
			mockStore.js
		system/
			projectLifecycle.js
		unit/
			widgets/
				foo.js
	node_modules/
		intern/
	package.json