Add unittest and functional test infrastructure

[Steffen Hoffmann]

Securing the code against regressions by changes done in ongoing development requires checks for existing functionality and user-webUI-interaction.

Automated testing is best practice for programming QA because it yields high, permanent effect for any effort put into it.

[Steffen Hoffmann]

Odd, you may take this ticket over as you see need to express your commitment to the task.

And I've seen you reopening #3983. I understand the value of these tests and will try to follow. Isn't it possible to execute these doctests too along with the unittests? At least I think that I've seen doctests and infrastructure for them in Trac core as well...

[osimons]

Yup, pretty much got it ready. Hang on...

[osimons]

(In [10670]) TagsPlugin: Wired up unittest infrastructure for all modules, including the existing doctests part of query module.

16 tests, ~half are dummy tests to verify test infrastructure, and 1 doctest is failing due to #3983 (already reopened).

Tests can be run either as the full suite:

$> PYTHONPATH=. python setup.py test

or, by just running a single test module:

$> PYTHONPATH=. python -m tractags.tests.query

Closes #9194 - now go write some more tests... :-)

[osimons]

(In [10671]) TagsPlugin: Adding some slightly more elaborate web_ui test cases to ensure that basic request handling and permissions work.

References #9194.

[Steffen Hoffmann]

(In [13165]) TagsPlugin: Mirror ticket tags into normalized tags db table, refs #4503, #9194 and #11096.

Parsing ticket fields per request has been a known performance hog, that's why using the tags db table for regular access yields a considerable speed-up.

As a side-effect 'ticket' is the pilot for fixing a recently announced issue with get_tagged_resources in the default tag provider implementation. Nicely polished by stretching unit test coverage to this part of the code.

ToDo: DefaultTagProvider must be fixed as well, and other tag providers should be reviewed too as a precaution.