Erratic test in RegularExpressionGeneratorTest about autofixture HOT 10 CLOSED

Very tricky.. It fails when the generated regular expression is "(\nl".

\n is treated as a line break so the result becomes:

// Output from Text Visualizer:
(
l

from autofixture.

In the unit test, the assertion has been (implicitly) setup to match any character except \n:

if (Regex.IsMatch(regex, pattern))
{
}

We need to pass RegexOptions.Singleline in order to match every character (instead of every character except \n):

if (Regex.IsMatch(regex, pattern, RegexOptions.Singleline))
{
}

Testing it using an infinite loop — The assertion never fails now.

from autofixture.

Pretty awesome detective work :)

What is the cost of using RegexOptions.Singleline? By adding that, are there now regular expressions we can't deal with? Were there regular expressions before that we couldn't deal with, that we can deal with now?

What does the [RegularExpression] attribute use when it validates input? RegexOptions.Singleline or one or more of the other flags?

I'm just trying to figure out if this is innocuous or really a breaking change...

from autofixture.

Good suggestion!..

There is no way to pass RegexOptions to the [RegularExpression] attribute.. I also had a look with Reflector and the options seem to be hardcoded.

As it seems, the [RegularExpression] attribute uses the default options:

string input = "(\nl";
string pattern = @"\(.*l";

bool result = Regex.IsMatch(input, pattern);
// Prints -> false

var attribute = new RegularExpressionAttribute(pattern);
bool result = attribute.IsValid(input);
// Prints -> false

However, it is now easier for us — We could remove the test case with the @"\(.*l" pattern as it makes the test to behave erratically.

Optionally we could also validate the result using the attribute's built-in RegularExpressionAttribute.IsValid instance method (instead of using the Regex.IsMatch static method).

How does that sound?

from autofixture.

I think those suggestions sound good - I think the most important thing here is to stay in sync with what the [RegularExpression] attribute expects. After all, we should rather not produce a value that can't be validated by the attribute itself.

from autofixture.

Yes, exactly that..

from autofixture.

Here's another error that occasionally pops up:

Test 'Ploeh.AutoFixtureUnitTest.RegularExpressionGeneratorTest.CreateWithRegularExpressionRequestReturnsCorrectResult(".gr")' failed:
result: Ploeh.AutoFixture.Kernel.NoSpecimen
RegularExpressionGeneratorTest.cs(62,0): at Ploeh.AutoFixtureUnitTest.RegularExpressionGeneratorTest.CreateWithRegularExpressionRequestReturnsCorrectResult(String pattern)

from autofixture.

I have just checked it and it fails when the value is '\ngr' (similar to the above). It should also be removed since we can't pass RegexOptions to the [RegularExpression] attribute..

from autofixture.

I have just added the commits to a Pull Request.

from autofixture.

Resolved (changesets f41ffc3 and 7eb4613)

from autofixture.