Update "main" to support running testgroups and 'execute'.
This changes the "main" portion of the script to support usage like:
- show usage:
git-ubuntu-self-test --help
- run the provided testgroup[s]
git-ubuntu-self-test <testgroup> [<testgroup]
the testgroups are: pipcheck mainhelp pylint pytest
To run just the 'mainhelp' test:
git-ubuntu-self-test mainhelp
- run all test groups:
git-ubuntu-self-test
- execute any command in the snap environment.
git-ubuntu-self-test execute <command> [args]
Also puts a nice 'SUCCESS' or 'FAIL' as the last line in a run.
Coupled in, there are further changes to the 'mainhelp' testgroup
to actually just execute 'python3 -B <script> --help' rather than
attempting to compile.
Also, drop the python -B usage. It does not seem necessary.
You can test the files in the snap with the self-test from the tree
by doing:
Several changes here to the logic in quick compilation check:
a.) pass -B when trying to execute --help for a script.
-B is present in the current snap ()
$ which python3
/snap/git-ubuntu/463/usr/bin/python3
$ python3 --version
Python 3.6.3
$ python3 --help | grep -- -B
-B : don't write .pyc files on import; also PYTHONDONTWRITEBYTECODE=x
b.) test compilation of git-ubuntu script also (by copying it to
git-ubuntu.py so that 'python3 -m' finds it)
c.) use PYTHONPATH rather than symlink in tmpdir to find gitubuntu
module during test compilation.
d.) add 'test_what' variable to easily determine if this is a 'snap'
test or a 'tree' test.
e.) catch errors in the compilation failure. before these were not
accounted for in retval.
Add support for executing self test in checked out tree.
git-ubuntu is expected to run in the snap environment, and the self test
is also. Building a snap just to run tests is painfully slow.
The solution here is to run the tests in an already-existing snap
environment. This does present a bit of a chicken-egg problem, but one
that is only exposed when we add new python dependencies to git-ubuntu.
git-ubuntu-self-test is modified to accept a TEST_TREE environment
variable and do the right thing in both snap environment and development
tree.
So now both of these work:
# test the snap installed git-ubuntu libraries.
$ git-ubuntu.self-test
# test the tree in "."
$ ./snap-wrappers/wrappers/git-ubuntu-self-test
Also done here:
* place 'SNAP_REVISION' and 'SNAP_VERSION' into environment.
these are just informative. And a useful message is printed
in the test output about the snap environment being used.
README.testing is updated with some documentation on how to run
git-ubuntu.self-test without building a snap and installing it first.
In various places we have two implementations of near-identical code
where the only difference is whether they act on unapplied or applied
branches, tags or structure. Ultimately they do need to be handled
differently at some point, but most of the code in the middle of the
call graph does not need to care.
To avoid code duplication we define a PatchState enum and can then drop
half of the middling code by simply passing through the "unapplied-ness"
or "applied-ness" as a parameter.
The following functions are removed from gitubuntu.git_repository.
Instead, the unapplied previous equivalent should be used with
patch_state=PatchState.APPLIED:
The following methods are removed from
gitubuntu.git_repository.GitUbuntuRepository. Instead, the unapplied
previous equivalent should be used with patch_state=PatchState.APPLIED:
A grep suggests that the only callers are importer.py and
importer_test.py; these are refactored as part of this change, dropping
duplication where there was any.
"git ubuntu tag" is the obvious CLI command that might have been
affected, but it doesn't appear to need any of these functions or
methods. Perhaps it should, but that's a job for a future refactoring.
This change does not cover every instance of code duplication or where
refactoring to use the new enum might be appropriate; we merely fix the
code that needed touching anyway, leaving other refactoring for the
future.
This change should not result in any functional changes.
The script will exit non-zero if any of a set of tests fail, but it
isn't necessarily obvious from the output what was a warning and what
caused the failure. Let's make this obvious in the output. In all cases
where we set a future failure, explicitly tell the caller via stdout.
