More flexibility in subclassing functional test infrastructure

[osimons]

I'd like to reuse the functional test infrastructure for plugin tests. However, all commands are 'hardwired' to presume they are run as Trac tests with '.' as common base source directory.

With plugin tests, I'd need just Trac source being on path to make test infrastructure importable and callable, but will create my own test environment inside plugin source.

To handle common base + allow for running any internal 'tweaks', I've made a patch that I think is a nice clean solution for this:

• It adds a self.trac_src variable that just defaults to '.'
• All command calls are updated to do os.join() on the common base
• Added a init() hook that a subclass can implement to adjust any internal settings before any methods are called

I haven't been much involved in testing so far, so I'd like input from others before taking any actions - even though subclassing the infrastructure have been quite insightful...

Patch follows. All regular Trac tests pass fine, and I'm able to create a plugin test infrastructure in 25 lines of code. Nice :-)

[osimons]

Easier reuse of functional test infrastructure.

[ecarter]

Looks good. I'd like to get Tim to give it the once-over in case I'm missing something.

[cboos]

Looks good to me as well. You can already commit it on the rework-testing branch, if it needs more work, we can do it there before propagating the change to 0.11-stable and trunk.

[osimons]

Oki. Committed to branch in [8268].

[osimons]

BTW, I've committed the test infrastructure for the ​trachacks:wiki:XmlRpcPlugin that uses/depends on this patch: ​trachacks:changeset:6064 (see tests/__init__.py for how it is used).

[osimons]

This one should be ready to include in 0.11.5.

What is the merge-strategy for rework-testing back to 0.11-stable? Apply patch to 0.11-stable, merge to trunk, and then a --record-only merge in rework-testing to block it as it is already applied? Confused :-)

[cboos]

Replying to osimons:

This one should be ready to include in 0.11.5.

What is the merge-strategy for rework-testing back to 0.11-stable? Apply patch to 0.11-stable, merge to trunk, and then a --record-only merge in rework-testing to block it as it is already applied?

Yes, except for the last step: we haven't reintegrated yet any change from trunk on the rework-testing branch, and I think there's no point in doing so now. If new changes from trunk really need to be taken into account for further developments on the rework-testing topic, then we should rather recreate the branch, in order to avoid a huge merge changeset.

Confused :-)

Normal, we're doing crazy stuff in order to stress-test #7715 ;-)

[osimons]

Committed in [8305:8306].