Fix the Bech32 character mutation test.

[jonathanknowles]

Issue Number

Issue #331

Overview

The character mutation test occasionally fails, because it attempts to be extremely specific when pattern matching the error produced by decoding a mutated string.

Unfortunately, changing just a single character in a valid Bech32 string can cause the decoder to produce many different types of error, depending on the location of the mutation, and the nature of the mutation.

Work Done

• I have changed the character mutation test to be less specific: it now expects that the string is rejected with some error, but doesn't attempt to pattern match on the error.

This already gets us most of what we want, namely that mutating a character cause the resultant string to be rejected by the decoder.

[KtorZ]

@jonathanknowles I went for the approach of selecting indexes only within the data-part. This still gives us most of the property checks we care about and avoid replacing the separator by something that messes up the assertion

[jonathanknowles]

@KtorZ

@jonathanknowles I went for the approach of selecting indexes only within the data-part. This still gives us most of the property checks we care about and avoid replacing the separator by something that messes up the assertion

I think there are a few issues with this change:

1. The function chooseWithinDataPart gives us an incorrect upper bound for the index in the insertion, mutation, and deletion tests. These tests should limit their indices in subtly different ways:

   Test	Index Upper Bound	Notes
   Insertion	T.length originalString	(we can insert after the end of a string)
   Mutation	T.length originalString - 1
   Deletion	T.length originalString - 1
   Swapping	T.length originalString - 2	(we swap with the character to the right)

2. Limiting our choice of index to just the data part means that our tests become weaker, as we're no longer testing across the full length of a Bech32 string. Since the checksum is a function of both the data part and the human readable part, it makes sense to mutate both parts.

3. In particular, we do need to check for mixed case characters at all locations in the string, and not just in the data part:

   Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed case strings).
   So for the mixed-case tests, it also makes sense to mutate across the string.

I've created a PR for this, which I'll post shortly. 😃