0.4.1

[nth-commit]

Enhancements for generators

Gen.Two, Gen.Three, Gen.Four

Added a family of higher-order generators, which take a generator and return a new generator of a tuple, whose values are sourced from the original generator.

Gen.Int32().Two(); // (0, 0), (0, 1), (1, 4) ...
Gen.Int32().Three(); // (0, 0, 0), (0, 1, 2), (1, 4, 3) ...
Gen.Int32().Four(); // (0, 0, 0, 0), (0, 1, 2, 4), (1, 4, 3, 9) ...

Gen.Set

Added another higher-order generator, that takes a generator and returns a new generator for sets, whose elements are sourced from the original generator. The values it returns are of type IReadOnlyCollection<T>, as that is the most fundamental immutable "set"-like interface in the core framework. ISet<T> was considered, but it's methods hint towards mutability, which breaks shrinking.

The API has familiar configuration methods to Gen.List, Gen.String for specifying the range of counts that are acceptable for generated sets.

Gen.Int32().SetOf().WithCountLessThanEqual(10); // Only generates sets with less than 10 elements

Sometimes you need to stop trying

Unlike other property-based testing frameworks, GalaxyCheck has exhaustion protection built-in as a fundamental property of generators. Other frameworks have similar protections, but only at the property level. This means you can discard/filter values inside the test method, and excessive filtering will cause the property to fail.

However, discards inside the generators passed to your property will not be tracked. It's easy to mistakenly construct a generator that never complete, which cause tests to hang, mysteriously. Sometimes the preconditions that caused the generator to struggle are disconnected (like in different functions, for example).

GalaxyCheck detects excessive discards everywhere and will bail out of such generation attempts, for example:

Func<int, bool> isEven = x => x % 2 == 0;
Func<int, bool> isOdd = x => x % 2 != 0;

return 
    from x in Gen.Int32()
    where isEven(x)
    where isOdd(x)
    select x;

The newly-introduced set generator leverages the same behaviour. This means that GalaxyCheck won't hang when trying to generate impossible sets (or sets that are really hard to fill). Instead, the following code will crash:

Gen.Boolean().SetOf().WithCount(3); // Can't generate three distinct booleans, saaahhhrreeeey

The set generator will also do just fine when you don't explicitly tell it what count you want, either. For example:

Gen.Boolean().SetOf(); // { }, { true }, { false }, { true, false }
Gen.Int32().SetOf(); // { }, { 0, 1, 2 }, { 2, 4, 6, 8, 10, 3, 5, 7, 9 } ... 

Gen.Create now knows about sets

This release also wires up a few of the .NET set types to the set generator, meaning reflection-based properties that have sets as parameters will now work out-of-the-box.

[Property]
public void GameSetAndMatch(ISet<short> setOfShorts, HashSet<int> setOfInts, ImmutableSet<long> setOfLongs)
{
}

Note, IReadOnlyCollection<T> is still handled by the list generator, by default.

FlagsAttribute variant of Gen.Enum now uses Gen.Set under-the-hood

Previously, it used Gen.List, which means the shrinks inherited the structure of that generator. Now, it uses Gen.Set, which greatly decreases the number of shrinks - as only distinct values will be bitwise-OR'd together, and there will be no shrinks dedicated to modifying the order of the bitwise-OR - removing ineffective shrinks.

This diff demonstrates what that means in practice.

Gen.Cast is more flexible

Previously, the following code would throw:

Gen.Int32().Cast<decimal>(); // Object of type 'System.Decimal' cannot be converted to type 'System.Int32'

This is weird, as there is a defined cast between those two types.

I'm pretty sure it's a limitation of boxing...

Anyway, in the latest version, if casting fails, the generator will try and do a Convert.ChangeType instead - which might work! (it does in this case). That's the best I can do right now.

BUGFIX: Gen.Create with could cause a list to only contain a single repeating value

A certain code-path through the reflection-based generator (specifically, an object inside a list) meant that the list might only contain a single-repeated value. This was because the reflection generator for types with a default constructor, would only ever create one instance. Then, inside the generator body, it would call PropertyInfo.SetValue/FieldInfo.SetValue.

This was fixed in this version, by moving the object creation inside the generator body.

---

This discussion was created from the release 0.4.1.