Hi,
On Thu, Feb 23, 2023 at 12:20 AM Michael Meeks <michael.meeks@xxxxxxxxxxxxx> wrote:
Ooh - interesting; so would using the boxclipper's getRandomOrdinal -
which uses rand() and (I assume) could be consistently seeded ?
Or could we consistently seed:
comphelper::rng::uniform_size_distribution(
To produced a known pattern ? or we could hard-code a set of numbers
(which I guess) wouldn't provoke the problem into the test.
Well a unit test should be a set of known input (typical input values and known corner cases) that asserts a known output, which then defines the behaviour of the calling function or class. If you have random values for an input you don't really have a "known" set of input values as they are generated every time. Would be much better to change this test to a simple set of known input values and also tackle the corner cases, which are missing (but we obviously do hit one).
Also getRandomOrdinal(1) is essentially a NOOP - always returns 0, so the aPolygonOffset was always offset by 0.5 from the other generated polygon, which is not what the intended use case for the test was.
Would be lovely to find the sequence that kills it of course,
It happens because getDeltaY() is 0.0, which is the "end - start" Y value of an edge, but this one should never be zero (according to the comment).
I have run a simpler case in a loop but didn't get the value 0, so I could write an edge case unit test. Deconstructing the code and unit test the parts would probably be needed.
Thoughts much appreciated,
Michael.
--
michael.meeks@xxxxxxxxxxxxx <><, GM Collabora Productivity
Hangout: mejmeeks@xxxxxxxxx, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
Tomaž
