Again, this is a patch set that is centered around improving the tests for
MinimapDialog, but actually I'm largely trying to improve the facilities for writing reliable tests.
Couple of potentially controversial things in here.
First three patches are really just tidying of
MinimapDialogTest - nothing particularly interesting there. Then we have
Controversial patch number one: NavigatableComponent
Some changes to
MapViewState to make it able to successfully perform an
updateLocationState in unit tests. If we detect we're in headless mode, these patches rather *assume* that we're running unit tests and generate appropriate "mock" behaviour, e.g. our top level window is (10, 10) from the screen top left. To me, this is slightly preferable to requiring tests to do complicated mocking to get this to work which may or may not require large parts of
JOSMFixture to be re-evaluated etcetera...
There is an ongoing danger I can see though that we conflate "headless mode" with "test mode" which could end up biting us when cli/batch mode is taken into consideration. Don't know.
Controversial patch number two: ImagePatternMatching
Have I gone insane? Possibly. Testing images is difficult presuming you don't want to create fragile, possibly platform-specific "exact result" tests. When asserting properties about generated images (testing pixels etcetera) I found myself writing an awful lot of repetitive code until I got to the point I realized I was just doing manual pattern-matching. But we've got a well-known tool for concise pattern-matching, it's just that most implementations of it are designed to operate on strings of characters rather than pixel values - regexes.
ImagePatternMatching is a set of utility methods that will convert a row or column of an image into characters using a supplied mapping function, then attempt to match it against the given regex, returning the
Matcher. See in the example use -
MinimapDialogTest$testViewportAspectRatio - how straightforward it makes asserting that the viewport marker rectangle is in the center of the painted image, without being affected with any absolute sizes. It would require very few changes now to allow these tests to be parametrized across different
The example use cases just show matching against a simple block color palette, but a large amount of flexibility is revealed by using a user-specified palette mapping function. A range of pixel shades could be mapped to a single character, or the mapping could be based on just a single channel - it's up to the caller.
Isn't this going to be slow and memory inefficient? Hopefully not for just single rows or columns. I mentally toyed with the idea that an entire image could be checked with a single (albeit complex) regular expression if the palettization converted it into a multiline string, but let's just leave that in the "ideas" column for now (part of the problem with that would be that when failing, it would generally be unclear where in the image was causing the match to fail).
I realize I haven't added docstrings for these methods - wanted to show the work before going to that bother.
Patches based on r13169, also visible on github: