Re: Missing UAX#31 tests?

From: Karl Williamson via Unicode <unicode_at_unicode.org>
Date: Mon, 9 Jul 2018 14:11:02 -0600

On 07/08/2018 03:21 AM, Mark Davis ☕️ wrote:
> I'm surprised that the tests for 11.0 passed for a 10.0 implementation,
> because the following should have triggered a difference for WB. Can you
> check on this particular case?
>
> ÷ 0020 × 0020 ÷#÷ [0.2] SPACE (WSegSpace) × [3.4] SPACE (WSegSpace) ÷ [0.3]

I'm one of the people who advocated for this change, and I had already
tailored our implementation of 10.0 to not break between horizontal
white space, so it's actually not surprising that this rule didn't break
>
>
> About the testing:
>
> The tests are generated so that they go all the combinations of pairs,
> and some combinations of triples. The generated test cases use a sample
> from each partition of characters, to cut down on the file size to a
> reasonable level. That also means that some changes in the rules don't
> cause changes in the test results. Because it is not possible to test
> every combination, so there is also provision for additional test cases,
> such as those at the end of the files, eg:
>
> https://unicode.org/Public/11.0.0/ucd/auxiliary/WordBreakTest.html
> https://unicode.org/Public/10.0.0/ucd/auxiliary/WordBreakTest.html
>
> We should extend those each time to make sure we cover combinations that
> aren't covered by pairs. There were some additions to that end; if they
> didn't cover enough cases, then we can look at your experience to add more.
>
> I can suggest two strategies for further testing:
>
> 1. To do a full test, for each row check every combinations obtained by
> replacing each sample character by every other character in its
> partition. Eg for the above line that would mean testing every
> <WSegSpace, WSegSpace> sequence.
>
> 2. Use a monkey test against ICU. That is, generate random combinations
> of characters from different partitions and check that ICU and your
> implementation are in sync.
>
> 3. During the beta period, test your previous-version with the new test
> files. If there are no failures, yet there are changes in the rules,
> then raise that issue during the beta period so we can add tests.

I actually did this, and as I recall, did find some test failures. In
retrospect, I must have screwed up somehow back then. I was under tight
deadline pressure, and as a result, did more cursory beta testing than
normal.
>
> 4. If possible, during the beta period upgrade your implementation and
> test against the new and old test files.

>
> Anyone else have other suggestions for testing?
>
> Mark
>

As an aside, a release or two ago, I implemented SB, and someone
immediately found a bug, and accused me of releasing software that had
not been tested at all. He had looked through the test suite and not
found anything that looked like it was testing that. But he failed to
find the test file which bundled up all your tests, in a manner he was
not accustomed to, so it was easy for him to overlook. The bug only
manifested itself in longer runs of characters than your pairs and
triples tested. I looked at it, and your SB tests still seemed
reasonable, and I should not expect a more complete series than you
furnished.
>
>
> Mark
> //////
>
> On Sun, Jul 8, 2018 at 6:52 AM, Karl Williamson via Unicode
> <unicode_at_unicode.org <mailto:unicode_at_unicode.org>> wrote:
>
> I am working on upgrading from Unicode 10 to Unicode 11.
>
> I used all the new files.
>
> The algorithms for some of the boundaries, like GCB and WB, have
> changed so that some of the property values no longer have code
> points associated with them.
>
> I ran the tests furnished in 11.0 for these boundaries, without
> having changed the algorithms from earlier releases.  All passed 100%.
>
> Unless I'm missing something, that indicates that the tests
> furnished in 11.0 do not contain instances that exercise these
> changes.  My guess is that the 10.0 tests were also deficient.
>
> I have been relying on the UCD to furnish tests that have enough
> coverage to sufficiently exercise the algorithms that are specified
> in UAX 31, but that appears to have been naive on my part
>
>
Received on Mon Jul 09 2018 - 15:11:28 CDT

This archive was generated by hypermail 2.2.0 : Mon Jul 09 2018 - 15:11:28 CDT