Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Matcher checking a string matches a regular expression #36

Closed
Derbeth opened this issue Jun 28, 2013 · 20 comments · Fixed by #57
Closed

Matcher checking a string matches a regular expression #36

Derbeth opened this issue Jun 28, 2013 · 20 comments · Fixed by #57
Milestone

Comments

@Derbeth
Copy link

Derbeth commented Jun 28, 2013

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
Copy link

lanwen commented Jun 28, 2013

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
Copy link
Contributor

npryce commented Jun 28, 2013

@Derbeth
Copy link
Author

Derbeth commented Jun 28, 2013

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
Copy link
Contributor

npryce commented Jun 28, 2013

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
Copy link
Author

Derbeth commented Jun 29, 2013

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
Copy link

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
Copy link

bacar commented Jan 25, 2014

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

@npryce
Copy link
Contributor

npryce commented Jan 28, 2014

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
Copy link

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

@tomwhoiscontrary
Copy link

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
Copy link
Contributor

npathai commented Dec 18, 2014

@tomwhoiscontrary Maybe soon #65

@npryce npryce added this to the 7.0 milestone Dec 23, 2014
@jm2dev
Copy link

jm2dev commented Jan 28, 2015

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
Copy link

alexec commented Aug 9, 2015

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

@sf105
Copy link
Member

sf105 commented Aug 9, 2015

@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
Copy link

+1

@edbrannin
Copy link

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
Copy link

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

@edbrannin
Copy link

edbrannin commented Nov 17, 2016

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
Copy link

rdp commented Jan 23, 2019

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
Copy link

matchesRegex

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.