This includes:
* Ability to specify number of processes to run bok-choy tests in
* A forked nose commit to get the multiprocess plugin's logging to work
* A different plugin (xunitmp) must be used for pulling together xunit results
This works by:
* Starting the various servers that are needed for the acceptance test environment
* Running the tests themselves in multiprocess mode
The platform includes jshint as a development tool, and our
builds are enforcing a limit on total number of jshint violations.
This commit will enforce no new jshint violations on a per-change
basis, much like pylint and pep8 are enforced. So with this change,
we'll be enforcing our linting requirements consistently, regardless
of type of violations.
Also on Jenkins, runs quality task after installing jshint.
This is the default in 3.2, but will need to be explicitly stated in
Sass 3.4.
Also, added a --force parameter to compile_sass to make it easier to see
what warnings are current.
The old line:
from path import path
produced pylint errors because of the baroque way that path.py defined
"path". We tried to get them to change how they defined it, but they
deleted the name instead: https://github.com/jaraco/path.py/issues/102
(Jason then changed his mind, but this is a better way to use path.py,
it avoids the pylint error at least.)
This complexity metric is created by using radon (see changed files for additional
documentation links). This tool calculates cyclomatic complexity and provides a numeric grade
where a lower number is better (e.g., less complex).
JShint will be executed with paver run_jshint, which will use a defined set of
directories (likewise defined are directories to ignore). A limit can be imposed
on the total number of violations. Note that this change does NOT include adding
jshint to diff-quality or `paver run_quality`.
This would allow a user to set up and run servers, with an open prompt for killing
them. Likewise a user could open a different terminal session and run tests only.
How-to:
* At a terminal/ssh session, start bok-choy servers with
`paver test_bokchoy --serversonly`
(or, if you've already run collectstatic on your system:
`paver test_bokchoy --serversonly --fasttest`)
* When the above is running, you can now open a separate terminal/ssh session
and run:
`paver test_bokchoy -t my_tests --testsonly`
Keep in mind, the 'testsonly' flag does no setup. There is some minimal teardown; however,
such as clearing mongo and flushing the lms database. (Some tests have non-unique identifiers
and could not be run more than once.)
This adds the -l switch, wherein a violations limit is passed in. For
example:
paver run_pep8 -l 700
Will fail if more than 700 violations are found.
By default, this limit is not enforced (i.e. if the -l switch
is not passed into the command, then a limit will not be put
into effect for that run)
