search

LiTiang / js-test-driver

Automatically exported from code.google.com/p/js-test-driver
0 stars 0 forks source link

Allow includes in configuration file #333

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
As a Sinon.JS user, I would like to be able to add Sinon as a submodule within 
my JS tree, and include the jsTestDriver.conf from that library in my own 
config file.
This way I won't have to keep track of changes to that library in my own 
config. For example:

include:
  - vendor/sinon/jsTestDriver.conf

load:
  - lib/MyLib.js

test:
  - test/MyTest.js

Original issue reported on code.google.com by yitzchak...@gmail.com on 7 Feb 2012 at 5:56

GoogleCodeExporter commented 9 years ago 
Seconding this, I would prefer to have configuration files on a per-module 
basis, with all the units relevant to that module. Rather than making new 
configuration files for multiple modules, I'd much rather have a configuration 
file for the suite as a whole that was nothing but inclusions.

In addition, this facility would be useful to put common test configurations in 
a common file.

For this use case, here are my suggestions for operations on the various 
sections. These might not be as general as could be written, but would be 
enough to get started.

include: Require it to be the first directives, if present. This eliminates 
confusion about implied priority from order of appearance.

server,proxy: One consistent definition. Conflicting definitions are an error. 
Multiple definitions are not an error as long as the definitions are identical.

load,test: Load the union of self-defined files and all included files in 
depth-first-search order.

exclude: Set-difference (item removal) of all specified files for this 
configuration. Therefore, a file excluded in one configuration might be 
subsequently be included in a sibling configuration.

serve: Serve the union of self-defined files and all included files.

plugin: Load all plugins. Require that matching "name" fields have identical 
definitions for all remaining fields.

timeout: Provides an overridable default. The default applies for the present 
configuration and all that include it, that is, bottom-up rather than top-down. 
If two siblings provide an differing timeouts, no default value is created.

There are only a few primitive operations on configuration fields needed to 
implement all this: (1) Depth-first search and file list construction, (2) 
Identical definition checking, (3) Propagation of default values.

Original comment by eric.eh9@gmail.com on 12 Apr 2012 at 3:33

GoogleCodeExporter commented 9 years ago 
A second comment. It's apparent after thinking about the file list operation 
that file exclusion is properly a sub-specification of "load", "test", and 
"serve". Without breaking current configuration files, the following syntax 
could be used in addition to the present:

test:
  - include:
    - ...
    - ...
  - exclude:
    - ...

This maps a scalar to a sequence of (maps from scalar to sequence). The current 
syntax for "test" etc. is map of a scalar to a sequence, so these are 
distinguishable by YAML type.

Original comment by eric.eh9@gmail.com on 12 Apr 2012 at 3:47

GoogleCodeExporter commented 9 years ago 
My use case: I have 2 config files (1 with code coverage, the other without). 
It'd be nice to include a common base config file. instead of copy and pasting 
into the 2 config files.

Original comment by ehu...@mobileiron.com on 2 Jul 2012 at 8:50