Matcher checking a string matches a regular expression

[Derbeth]

I cannot find any class allowing me to write my tests like:

String actual = tested.buildUrlWithRandomPort("foo", "bar");
assertThat(actual, matchesRegex("^foo://bar:\\d+/$");
// fails with a message like:
// expected <foo://bar:/> to match a regular expression <^foo://bar:\d+/$>

I think that Hamcrest Library should offer matchesReges() together with containsString(), endsWith() and startsWith().

Is there a matcher like this available in the master branch? If not, I could write one (something similar to Hamcrest Regex Matcher) and create a pull request.

[lanwen]

Here the one (i found it on google page of hamcrest) - https://github.com/derari/cthul/wiki/Matchers#string-matchers
Also, u can find some other here - https://github.com/yandex-qatools/matchers-java

[npryce]

There's also http://code.google.com/p/hamcrest-text-patterns/

[Derbeth]

hamcrest-text-patterns does the opposite thing than I asked for.

Ok, cthul looks nice, however I think that matching against a regex is such a core functionality that you should not require users to use third-party libraries. This would be the same bizzare situation as with C++ failing to provide a standard regex implementation. I think that when you write some test code, you constantly come across writing assertions making use of regular expressions. See how RSpec constructed its documentations: regexes are emphasised there.

As cthul is MIT-licensed, I suggest you copy the regex-related classes to hamcrest-library, adding cthul authors to the contributor list (to fulfil the legal licence requirements).

[npryce]

In what way does hamcrest-text-patterns do the opposite thing to what you asked for? It is a hamcrest matcher that matches strings against regular expressions. What do you want?

[Derbeth]

Ok, you are right, the section "Matching" shows regex-like matching, however, if I understand correctly, you need to use library builders to construct a matcher and you are not allowed to use normal regular expressions given as strings. I find this way of writing assertions way to verbose in many cases.

[TJamesBoone]

Derbeth is right. Hamcrest ought to have a simple, non-verbose regex matcher. There are many good reasons to and no good reasons not to.
The point is, I should be able write something like this:

Matcher<String> regexMatcher = Matchers.matchesRegex([insert regex expression here]);

Quick. Easy. Simple. No third party integrations required, no matter how clean.

[bacar]

Is there an objection to implementing this, or just no commits / pull requests for it?

[npryce]

No objection. There used to be a RegexMatcher in Hamcrest but it got removed because it made supporting different JDK versions difficult. But that was a very long time ago; Hamcrest no longer supports JDK versions without java.util.Pattern.

[btilford]

I end up writing one every single project I work on.

[tomwhoiscontrary]

Any idea when there might be a release with this matcher in? So far, i've copied and pasted it into two projects, and i'm going to die of shame if i have to do it again!

[npathai]

@tomwhoiscontrary Maybe soon #65

[jm2dev]

Assuming there is no matcher for regular expressions, you may consider to rewrite your assertion to something like this:

assertThat("Expected result matches regular expression", 
  expected.matches(regularExpression),
  is(true));

[alexec]

This would be awesome, one of the great thing about Hamcrest is the clear diagnostics.

[sf105]

@jm2dev I don't understand your point. Where does the actual value go? Also, if it fails, you just get an expected: true, was: false.

[AndersDJohnson]

+1

[edbrannin]

It turns out this was released as part of java-hamcrest 2.0.0.0 -- you'll also want to add hamcrest-junit to your project if you upgrade from 1.3, and use its assertThat() instead of the one in jUnit 4.

[tomwhoiscontrary]

Is Hamcrest 2 actually a thing? I thought it was an abortive sally.

[edbrannin]

There doesn't seem to be much documentation, but it's published to Maven Central. I was able to put it & the new JUnit integration in pom.xml and get my project building.

The main issue was I couldn't import static org.junit.Assert.*; anymore (for older test cases that still use assertEquals, etc.) because the two different assertThat() implementations got ambiguous.

[rdp]

For followers, confirm there is a MatchesPattern.matchesPattern(String regex) and MatchesPattern.matchesPattern(Pattern pattern) in 2.0, ex: assertThat(myString, matchesPattern("my regex"))

[parameshjava]

matchesRegex

There is no such method, can you please let me know which version hamcrest you are refering?