Opened 15 years ago
Closed 15 years ago
#8388 closed enhancement (fixed)
More flexibility in subclassing functional test infrastructure
| Reported by: | osimons | Owned by: | osimons |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.11.5 |
| Component: | general | Version: | 0.11-stable |
| Severity: | normal | Keywords: | |
| Cc: | felix.schwarz@… | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
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_srcvariable 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 :-)
Attachments (1)
Change History (10)
by , 15 years ago
| Attachment: | t8388-testenv_subclass-r8265-011.diff added |
|---|
comment:1 by , 15 years ago
| Owner: | set to |
|---|
comment:2 by , 15 years ago
| Cc: | added |
|---|
comment:3 by , 15 years ago
Looks good. I'd like to get Tim to give it the once-over in case I'm missing something.
comment:4 by , 15 years ago
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.
comment:6 by , 15 years ago
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).
follow-up: 8 comment:7 by , 15 years ago
| Milestone: | 0.11.6 → 0.11.5 |
|---|
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 :-)
comment:8 by , 15 years ago
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-onlymerge 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 ;-)
Easier reuse of functional test infrastructure.