#16700 closed enhancement (fixed)
[PATCH] tests: add new tests exercising handling of plugins that advertise multiple versions for compatibility
Reported by: | ris | Owned by: | team |
---|---|---|---|
Priority: | minor | Milestone: | 18.09 |
Component: | Unit tests | Version: | |
Keywords: | plugin tests version | Cc: |
Description
https://github.com/openstreetmap/josm/pull/34
Spurred by #16622, this "multi-version" functionality was not exercised by any tests. As ever when writing tests of the plugin handling code, I found an amount of probably-not-ideal behaviour which this now at least documents.
To make this easier, in these patches I introduced a basic mechanism for being able to override JOSMTestRules
settings on a per-test-method basis using annotations. I only used the annotation @JOSMTestRules.OverrideAssumeRevision
in these tests, but I also added @JOSMTestRules.OverrideTimeout
as I saw it as something that could be immediately useful and was a good example of how this pattern could be continued to useful ends.
From that changeset's comment:
JOSMTestRules: give JOSMTestRules a mechanism to allow per-method overrides of rule options
The caveats here are that it will only ever be possible to "add" additional options to the rule in the same way options can be appended to a call chain already (because they're processed using the same mechanism). Annotations can also only ever take primitive types as arguments (so no specifying new .fakeImagery(TileSourceRule ...) arguments)
Which I think says enough. Appveyor and (headless) travis passing. Attaching patches...
Attachments (2)
Change History (10)
Changed 2 years ago by
Attachment: | v1-0001-JOSMTestRules-give-JOSMTestRules-a-mechanism-to-a.patch added |
---|
Changed 2 years ago by
Attachment: | v1-0002-tests-add-new-tests-exercising-handling-of-plugin.patch added |
---|
comment:2 Changed 2 years ago by
Milestone: | → 18.09 |
---|
comment:4 Changed 2 years ago by
Milestone: | → 18.09 |
---|
comment:6 Changed 2 years ago by
referenceQuxJarNew is not used, why?
Good question.
After I'd written the test I realized I didn't need to actually serve it at all as it wasn't destined to be the downloaded version or the version whose metadata was used in the listing. But I didn't remove it because I'd gone to the bother to generate four mock plugins which is a bit of a chore to do, so didn't remove the extra one because it hypothetically is used in a more complete version of this test (which doesn't exist yet).
Again, these are git-style patches (i.e. they include binaries - the sample .jars) that can be applied to any source tree using
git apply
.