Assertions that use an existing Regex

[oznetmaster]

As far as I can tell, there are no assertions, in either model, that allow the use of an existing Regex in the assertion.

All of the Regex assertions take a string containing the regex pattern.

It would be quite useful to have constraints which take an existing Regex in place of the string pattern, but function identically.

[stevenaw]

I really like this idea. I think it could also provide a more explicit API. Passing regex as strings is simplest for a caller, but passing a regex object most clearly communicates intent, in my opinion.

[oznetmaster]

It is trivial to use Regex.ToString to recover the original Regex source text, but that is not the issue.

In many cases, the code being tested has a defined Regex that it would be nice to be able to test with.

Since the framework internally converts the string to a Regex anyway, passing the Regex directly would just eliminate that step and guarantee that it was a valid Regex. Everything else would be the same.

[stevenaw]

Out of curiousity, is this something that a PR is desired for (and if so, would it be suitable for new contributors)? A co-worker was recently asking me about ways to get involved with OSS, and it got me thinking about this issue.

[CharliePoole]

@rprouse Could you triage this issue, please? FWIW, it seems like a good idea for an enhancement or feature to me.

FYI, the Wiki still says "If there is no is: label, then we presumably don't know what the item is and should not be working on it!"

[stevenaw]

Absolutely, thanks for helping get this triaged @CharliePoole !

[rprouse]

This seems reasonable. I've made this an enhancement.

[Poimen]

I was having a quick look into this...

From the documentation, the Regex constraint works like:

string phrase = "Make your tests fail before passing!";

Assert.That(phrase, Does.Match("Make.*tests.*pass"));

Is the issue about making the API:

var regexCheck = new Regex("Make.*tests.*pass");
var phrase = "Make your tests fail before passing!";
Assert.That(phrase, Does.Match(regexCheck));

?

Assuming this is correct, the current RegexConstraint inherits from the StringConstraint which would make sense currently in how it is being used. However, in the case that it takes a regex, I would think that you could go two ways:

1. Keep the hierarchy, and push the into a string and re-convert it later (easy-game, but might not be so performant)
2. Make RegexConstraint stand by itself so it can move an incoming string into a Regex object independently

My other thought was the API:

var regexCheck = new Regex("Make.*tests.*pass");
Assert.That(phrase, Does.Match(regexCheck).IgnoreCase);

doesn't really make too much sense...I mean would the provider of the regex would have setup the match condition already? Do you want to limit the API for this use case?

Depending on what you feel about the conditional IgnoreCase - as in if provided a RegEx object, should IgnoreCase even be an option - then would you require a StringRegexConstraint and RegexConstraint separated to handle this condition? The option #1 above could work-around those kind of decisions at the expense of the runtime.

Also, the RegexConstraint docs says:

Does.Match(string pattern)
Matches(string pattern)

I have used the Does.Match, but how does one use the Matches API? Example maybe?

Sorry for all the questions in one, I was walking through ideas in my head.

[CharliePoole]

Answering your last question:

Assert.That(someString, Is.Not.Null.And.Matches(pattern);

All constraints have a syntax element used in the middle of a constraint expression (Matches) and another used to start an expression (Does.Match).

[Poimen]

Thanks, that's great. I always forget the And syntax 🙈

[CharliePoole]

FWIW I just implemented this in tc-lite. Someone could port it pretty easily if desired.

[Poimen]

@CharliePoole I had a quick look over the changes you implemented on tc-lite. Although I'm not too au fait with the tc-lite structure, it looks like the syntax is slightly different from nunit. The tc-lite changes could be ported across quite easily (I don't mind doing that).

Would you be suggesting that the Assert API more look like:

Assert.That(phrase, Does.Match("Make.*tests.*pass", RegexOptions.IgnoreCase));

?

[CharliePoole]

I went with four possible options for the user...

Assert.That(phrase, Does.Match("Make.*tests.*pass"));

Assert.That(phrase, Does.Match("Make.*tests.*pass", RegexOptions.IgnoreCase));

var regex1 = (new Regex("Make.*tests.*pass");
Assert.That(phrase, Does.Match(regex1));

var regex2 = (new Regex("Make.*tests.*pass", RegexOptions.IgnoreCase);
Assert.That(phrase, Does.Match(regex2));

I also made the attribute stand on it's own, no longer a StringAttribute.

For NUnit, it's a bit trickier of course. There's backward compatibility to contend with.