hamcrest / javahamcrest Goto Github PK
View Code? Open in Web Editor NEWJava (and original) version of Hamcrest
Home Page: http://hamcrest.org/
License: BSD 3-Clause "New" or "Revised" License
Java (and original) version of Hamcrest
Home Page: http://hamcrest.org/
License: BSD 3-Clause "New" or "Revised" License
It seems that everyItem()
uses shortcut logic, i.e. stops diagnosis at the first mismatch.
Whilst possibly the best idea in the general case, it's painful if you have to keep re-running the test to find out what "the next problem" is in the collection - c.f. HTML form validation in the early days of the web.
Interestingly, hasItem()
(conceptually quite similar) does diagnose all the mismatches in the collection passed in. It would be good if these two approaches to a similar problem in the core
package were the same / closer.
As it happens, hasItem()
also describes itself differently in failed assertions... anyway since a test is worth a thousand words, or something:
package org.hamcrest.core;
import org.hamcrest.Matcher;
import org.junit.Test;
import java.util.ArrayList;
import static java.util.Arrays.asList;
import static org.hamcrest.AbstractMatcherTest.*;
import static org.hamcrest.core.Every.everyItem;
import static org.hamcrest.core.IsCollectionContaining.hasItem;
import static org.hamcrest.core.StringStartsWith.startsWith;
// Test is JDK 7+
public class EveryVsIsCollectionContainingTest {
public static final Matcher<String> TEXT_MATCHER = startsWith("a");
public static final Iterable<String> ITEMS = asList("b", "c");
public static final ArrayList<String> EMPTY = new ArrayList<String>();
@Test
public void descriptionsAreDifferent() {
// <T> Matcher<Iterable<? super T>>
assertDescription("a collection containing a string starting with \"a\"", hasItem(TEXT_MATCHER));
// <U> Matcher<Iterable<? extends U>>
assertDescription("every item is a string starting with \"a\"", everyItem(TEXT_MATCHER));
}
@Test
public void mismatchesAreDifferent() {
assertMismatchDescription("mismatches were: [was \"b\", was \"c\"]",
hasItem(TEXT_MATCHER), ITEMS);
assertMismatchDescription("an item was \"b\"", everyItem(TEXT_MATCHER), ITEMS);
}
@Test
public void emptyBehaviourIsDifferent() {
// Seems "correct", but still a bit confusing.
assertDoesNotMatch(hasItem(TEXT_MATCHER), EMPTY);
assertMatches(everyItem(TEXT_MATCHER), EMPTY);
}
}
isA()
method currently accepts parameter of type Class<T>
instead of Class<?>
.
The following example fails to compile:
Object cheese = new Cheddar();
assertThat(cheese, isA(Cheddar.class));
while one with instanceOf()
succeeds:
Object cheese = new Cheddar();
assertThat(cheese, is(instanceOf(Cheddar.class)));
public static org.hamcrest.Matcher isA(java.lang.Class type) {
return org.hamcrest.core.Is.isA(type);
}
means you have to cast the thing to the type you are asserting it should be. Really it should be a matcher of anything (Object) not T.
e.g.
class hierarchy Foo extends Bar
Bar thing = somemethod();
assertThat(thing, isA(Foo.class))
to assert that you are getting the right subclass back - yeah ok, it might not be the best test, but anyhow......
In the move from Google Code to GitHub we've lost the directory of add-on libraries.
While IsMapWithSize exists in the API to test for these conditions on a Map, they are hard to find. Most developers only use the Matchers facade to find matchers, so we end up with code that looks like this:
assertThat(aMap.entrySet(), Matchers,empty())
It would be nicer to write:
assertThat(aMap, Matchers.empty())
Publish to Maven Central as a single JAR file. Do not publish separate hamcrest-api and hamcrest-library JARs.
This will make things easier for client projects and simplify the build.
When we've reinstated the directory of add-on projects (issue #77), add a link to the chainable matchers in https://github.com/EZGames/ez-testing
Correct me if I'm wrong, but there is no easy way to assert that an object is an empty map.
I think we need a matcher similar to IsArrayWithSize from org.hamcrest.collection, offering methods like mapWithSize() and emptyMap().
If you confirm there is no such matcher available, I could implement it and offer a pull request.
Make sure they're all up to 2015.
The description of the org.hamcrest.text.StringContainsInOrder
stringContainsInOrder method is incorrect, and states that the matcher matches regardless of the order of apperance, but in fact it does check the order of apperance (as the method name suggests).
Additionally the example given doesn't help the matter either, by simplying indicating that the example would pass or fail would be useful.
Junit 4.11 includes that assertThat() that reports mismatches
It would be nice to have a varargs method for Matchers.stringContainsInOrder, so that instead of:
stringContainsInOrder(Arrays.asList("The", "trio", "arts"))
you can do:
stringContainsInOrder("The", "trio", "arts"))
Currently, equalTo()
will not compile when comparing Object
to another class forcing unnecessary casting. For example:
HttpServletRequest request = (get request);
Object actual = request.getAttribute("SomeAttribute");
assertThat(actual, equalTo((Object) fooInstance));
In this example, the compile will fail unless fooInstance
is cast to Object
. But this is unnecessary for equals()
to work correctly.
If the signature of equalsTo()
were:
Matcher<Object> equalTo(Object o)
it could avoid the above problem.
Hi There - Currently, TypeSafeMatcher.match return false if null or the wrong type is passed. I think this is likely to mask bugs in code
My suggestion for TypeSafeMatcher.match is:
public final boolean matches(Object item) {
if (item != null && !expectedType.isAssignableFrom(item.getClass())) {
throw new RuntimeException("Cannot match " + item.getClass().getName() + " with a type safe matcher for " + expectedType.getName());
} else {
return matchesSafely((T) item);
}
}
Are there other than me that would like to see a simple String length matcher in the core library for the upcoming release?
It was requested already more than a year ago, here https://code.google.com/p/hamcrest/issues/detail?id=191
(Please, let me know if I can help out in any way?)
I build all of my Java dependencies from source, and JavaHamcrest's use of qdox to generate CoreMatchers is a bit of a roadblock for me: qdox requires jflex to build, and jflex requires cup, which requires jflex. qdox also requires byacc to build. Anyway, it's a nest of circular build dependencies.
Why version CoreMatchers.java, despite being generated code?
(a) qdox is very hard to build without running binaries, as mentioned
(b) it's short and suitable for human review
(c) it's suitable for human modification without using qdox, in dire situations
Right now I'm copying CoreMatchers.java from a src jar and manually keeping it up to date.
Thanks for your consideration.
The overloaded methods were written to reduce compile warnings in client code. The @SafeVarargs annotation that was introduced in Java 7 suppresses them altogether.
This will change the ABI, but code will still be source compatible.
It just looks like the same exception as issue 25.
code:
@Test
public void testHamcrest() throws Exception {
List<Integer> list = Arrays.asList(null, null);
assertThat(list, IsIterableContainingInOrder.contains(null, null));
}
output:
java.lang.NullPointerException
at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.isMatched(IsIterableContainingInOrder.java:65)
at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.matches(IsIterableContainingInOrder.java:52)
at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:25)
at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:14)
at org.hamcrest.TypeSafeDiagnosingMatcher.matches(TypeSafeDiagnosingMatcher.java:55)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
at org.junit.Assert.assertThat(Assert.java:865)
at org.junit.Assert.assertThat(Assert.java:832)
There's a Hamcrest-Extras library that has matchers for Guava's Optional
. It would be cool to have the standard Hamcrest library provide these kinds of matchers for the pure JDK 8 Optionals
as well.
The following assertion never evaluate to true:
assertThat(null, either(equalTo(something)).or(nullValue()))
The root cause lies in the CombinableMatcher being a TypeSafeDiagnosingMatcher which implements matches()
as:
public final boolean matches(Object item) {
return item != null
&& expectedType.isInstance(item)
&& matchesSafely((T) item, new Description.NullDescription());
}
Thus for null
the matchers will never be queried. I suppose the solution should be something like:
public final boolean matches(Object item) {
return (item == null || expectedType.isInstance(item))
&& matchesSafely((T) item, new Description.NullDescription());
}
I have noticed that there are a few people using FEST-Assert instead of Hamcrest. After looking at it a bit it is really just syntactic sugar. Would it make sense to add something similar into Hamcrest so that people can use the syntax they like but still leverage the Matcher implementations. The FEST-Assert Condition class looks like a Matcher to me.
Any thoughts?
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.
The Is matcher doesn't do anything, and so should be deleted.
Factory methods for is should not be added to the domain-specific factory classes introduced as part of #85
Hi!
When I'm changing hamcrest version from 1.1 to 1.2 (or later) I get
java.lang.NoSuchMethodError: org.hamcrest.core.AllOf.allOf(Lorg/hamcrest/Matcher;Lorg/hamcrest/Matcher;)Lorg/hamcrest/Matcher;
I've seen discussion of this at http://code.google.com/p/hamcrest/issues/detail?id=173 , and the topic has come up in regards to doing the same for Junit (https://github.com/KentBeck/junit/issues/212). Is there any plan for this ?
https://gist.github.com/hertzsprung/5141786
Gives me
java.lang.AssertionError:
Expected: (hasProperty("myBoolean", <true>) and a collection containing "quux")
but: a collection containing "quux"
even though the collection was empty.
On use of equalToIgnoringWhiteSpace within is(...) Matcher-Decorator you got an java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
hamcrest-all, V1.1 works correct
Evolution of Hamcrest and JUnit has been held back by the dependencies between the two projects. If they can be decoupled, both projects can move forward with less coordination required.
Plan:
The uses of Hamcrest in JUnit are:
assertThat(Double.POSITIVE_INFINITY, closeTo(Double.POSITIVE_INFINITY, anyDouble))
should probably pass, but it fails. Same for Double.NEGATIVE_INFINITY
and Double.NaN
. A simple solution is to first check for equality.
There have been a number of changes since hamcrest-java-1.3
was released in 2012 and, for people who use Hamcrest's binary releases, it would be good to get them into a public 1.4 release.
There was some discussion on the mailing list back in 2013 about a Java Hamcrest 1.4 Release Plan, which suggested that #32 was the blocker for a release. However, discussion on that pull request now implies that a new release is unlikely.
A new release would be a great resolution for this, but it would also be good to have some expectation-setting, so users can decide whether waiting, making their own releases, or forking would be their best option for getting a current Hamcrest build, or if there's any way to help out.
The code generation complicates the build. But it's as easy to maintain the generated classes by hand.
We will:
IsIterableContainingInAnyOrder tries to describe the mismatch like this in Matching.isMatched, thus relying on toString:
mismatchDescription.appendText("Not matched: ").appendValue(item);
Rather it should use the same approach as IsIterableContainingInOrder and use the offending matcher to describe the mismatch. Here is what the IsIterableContainingInOrder Matcher does:
if (!matcher.matches(item)) {
describeMismatch(matcher, item);
return false;
}
Hello,
Unit test fail with JDK7. Tested with junit 4.11, Ant 1.8.4 and both OpenJDK 7 and Oracle JDK 7 with the following versions:
% java -version
java version "1.7.0_15"
OpenJDK Runtime Environment (IcedTea7 2.3.7) (ArchLinux build 7.u13_2.3.7-2-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
% java -version
java version "1.7.0_15"
Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
Some failing tests and output:
[junit] Testcase: testOnlyReadsPublicStaticAnnotatedMethodsThatReturnNonVoid(org.hamcrest.generator.ReflectiveFactoryReaderTest): FAILED
[junit] expected:<[g]oodMethod> but was:<[anotherG]oodMethod>
[junit] junit.framework.ComparisonFailure: expected:<[g]oodMethod> but was:<[anotherG]oodMethod>
[junit] at org.hamcrest.generator.ReflectiveFactoryReaderTest.testOnlyReadsPublicStaticAnnotatedMethodsThatReturnNonVoid(ReflectiveFactoryReaderTest.java:87)
[junit] Testcase: testReadsGenerifiedParameterTypes(org.hamcrest.generator.ReflectiveFactoryReaderTest): FAILED
[junit] expected:<...java.lang.String[]...> but was:<...[Ljava.lang.String;...>
[junit] junit.framework.ComparisonFailure: expected:<...java.lang.String[]...> but was:<...[Ljava.lang.String;...>
[junit] at org.hamcrest.generator.ReflectiveFactoryReaderTest.testReadsGenerifiedParameterTypes(ReflectiveFactoryReaderTest.java:178)
Is JavaHamcrest only compatible with Java 6?
public class HasItemTest {
@Test public void hasItemTest() {
Collection<String> collection = new ArrayList<String>();
assertThat(collection, hasItem(equalTo("foo")));
}
}
Gives the diagnostics
Expected: a collection containing "foo"
but:
Could we add something like but: was empty
?
The factory method Every.everyItem
currently returns a Matcher<Iterable<U>>
. Wouldn't a Matcher<Iterable<? extends U>>
make sense here? This would be in accordance with the guidelines for wildcard use.
Other collection matchers, such as IsIterableContainingInOrder
already do this.
From a ant -Dversion=1.3-redhat-1 bundle
(to try to make a bundle to use a
org.hamcrest:hamcrest-core:jar:1.3-redhat
that jnr-enxio is requires):
javadoc:
[javadoc] Generating Javadoc
[javadoc] Javadoc execution
[javadoc] Loading source files for package org.hamcrest.generator...
[javadoc] Loading source files for package org.hamcrest.generator.config...
[javadoc] Constructing Javadoc information...
[javadoc] Creating destination directory: "/usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-javadoc.jar.contents/"
[javadoc] Standard Doclet version 1.8.0_25
[javadoc] Building tree for all the packages and classes...
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:34: warning: no @throws for java.io.IOException
[javadoc] void writeHeader() throws IOException;
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:39: warning: no description for @param
[javadoc] * @param generatedMethodName
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:40: warning: no description for @param
[javadoc] * @param factoryMethodToDelegateTo
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:42: warning: no @throws for java.io.IOException
[javadoc] void writeMethod(String generatedMethodName, FactoryMethod factoryMethodToDelegateTo) throws IOException;
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:47: warning: no @throws for java.io.IOException
[javadoc] void writeFooter() throws IOException;
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:38: warning: no @return
[javadoc] public String getMatcherClass() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:53: warning: no @return
[javadoc] public String getName() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:65: warning: no @return
[javadoc] public String getGenerifiedType() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:75: error: invalid entity &ht;
[javadoc] * ie. 'public Matcher<...&ht;> blah(THIS, AND, THAT)'
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:75: error: bad use of '>'
[javadoc] * ie. 'public Matcher<...&ht;> blah(THIS, AND, THAT)'
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:77: warning: no @return
[javadoc] public List<Parameter> getParameters() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:89: warning: no @return
[javadoc] public List<String> getExceptions() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:101: warning: no @return
[javadoc] public List<String> getGenericTypeParameters() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:115: warning: no @return
[javadoc] public String getJavaDoc() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:9: error: self-closing element not allowed
[javadoc] * <p/>
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:9: warning: empty <p> tag
[javadoc] * <p/>
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:197: warning: no @return
[javadoc] public String getType() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:205: warning: no @return
[javadoc] public String getName() {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:15: error: tag not allowed here: <p>
[javadoc] * <p/>
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:93: error: self-closing element not allowed
[javadoc] * <p/>
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:93: warning: empty <p> tag
[javadoc] * <p/>
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:98: error: self-closing element not allowed
[javadoc] * <p/>
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:98: warning: empty <p> tag
[javadoc] * <p/>
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:101: warning: no @param for javaMethod
[javadoc] protected boolean isFactoryMethod(JavaMethod javaMethod) {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:101: warning: no @return
[javadoc] protected boolean isFactoryMethod(JavaMethod javaMethod) {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/SugarGenerator.java:62: error: reference not found
[javadoc] * @see ReflectiveFactoryReader
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/SugarGenerator.java:87: warning: no @throws for java.io.IOException
[javadoc] public void generate() throws IOException {
[javadoc] ^
[javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/SugarGen
11095 14-11-16 20:05:06 -0500 [master]
pdebuildx-amd64:/usr/local//a�
erator.java:44: error: reference not found
[javadoc] * @see ReflectiveFactoryReader
[javadoc] ^
[javadoc] Building index for all the packages and classes...
[javadoc] Building index for all classes...
[javadoc] Generating /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-javadoc.jar.contents/help-doc.html...
[javadoc] 8 errors
[javadoc] 20 warnings
BUILD FAILED
/usr/local/src/hamcrest-git/build.xml:118: The following error occurred while executing this line:
/usr/local/src/hamcrest-git/build.xml:256: Javadoc returned 1
Total time: 49 seconds
The source tree is organised into multiple source roots. This makes the build more complicated. Since 7.0 will be released as a single JAR (see #86), there is no need for different source roots.
I'm trying to upgrade to Java 8 and now any assertions using anyOf do not work.
assertThat("hello", anyOf(is("hello"), is("bye")));
I get the message:
The method anyOf(Matcher<capture#1-of ? super String>, Matcher<capture#2-of ? super String>) is undefined for the type TestPushEventMessage
I also tried:
assertThat("hello", anyOf("hello", "bye"));
And get the message:
The method anyOf(Matcher, Matcher<? super T>) in the type Matchers is not applicable for the arguments (String, String)
Trying to use jsonpath 1.1.0 (in conjunction with Spring MVC Test 4.1.0) results in the following:
java.lang.NoSuchMethodError: com.jayway.jsonpath.JsonPath.compile(Ljava/lang/String;[Lcom/jayway/jsonpath/Filter;)Lcom/jayway/jsonpath/JsonPath;
at org.springframework.test.util.JsonPathExpectationsHelper.<init>(JsonPathExpectationsHelper.java:54)
at org.springframework.test.web.servlet.result.JsonPathResultMatchers.<init>(JsonPathResultMatchers.java:43)
at org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath(MockMvcResultMatchers.java:183)
at id.co.bippo.product.rs.ProductControllerTest.showProduct(ProductControllerTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:72)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:81)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:216)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:82)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:60)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:67)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:162)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
See http://ggl-consulting.blogspot.com/2014/10/hamcrest-library-13-not-compatible-with.html
Has hamcrest 1.3 and junit 4.11
Code:
Object[] objects = new Object[] {null, null};
assertThat(objects, arrayContaining(null, null));
cause NullPointerException:
java.lang.NullPointerException
at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.isMatched(IsIterableContainingInOrder.java:65)
at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.matches(IsIterableContainingInOrder.java:52)
at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:25)
at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:14)
at org.hamcrest.TypeSafeDiagnosingMatcher.matches(TypeSafeDiagnosingMatcher.java:55)
at org.hamcrest.collection.IsArrayContainingInOrder.matchesSafely(IsArrayContainingInOrder.java:26)
at org.hamcrest.collection.IsArrayContainingInOrder.matchesSafely(IsArrayContainingInOrder.java:15)
at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:65)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
at org.junit.Assert.assertThat(Assert.java:865)
at org.junit.Assert.assertThat(Assert.java:832)
Why the JavaHamcrest is not built on Maven POM files?
I guess the committers would have easier life, and it is bulletproof to deploy Maven artifacts to the Maven central repository. Some features could be maybe already accepted if the Maven build was established.
I have a series of matchers that I want to assert, and they must all be true to be successful (all_of). However, when it fails, I really only want the failing one to be the description.
For example, the description for assertThat(2.2, closeTo(3.3, 0.5)
ends in "<2.2> differed by <0.6>", but should end in "<2.2> differed by <1.1>". That is, unless I'm misinterpreting the intended meaning of the message.
see original post:
https://code.google.com/p/hamcrest/issues/detail?id=205&sort=-id
i really would like to contribute that piece of code to the official project :)
kr,
christoph
Depends on #88
issue tracker
Readme and JavaHamcrest page
CoreMatchers and Matchers are now in the source and both compiled into the same JAR. CoreMatchers is therefore redundant. Matchers is growing larger and larger, to the point that autocomplete in the IDE is awkward.
Therefore,
Id like to be able to use the reflective type finder on any Matcher (to help with porting jmock to java 7). If we add a T argument to the dont_implement method on the Matcher interface then the type will be accessible.
Current Javadoc is:
assertThat("foo", isIn("bar", "foo"))
the elements amongst which matching items will be found
But should be:
assertThat("foo", isOneOf("bar", "foo"))
the elements amongst which matching items will be found
Right now, the code generator collects factory methods via reflection, which requires the compiled classes of the project to be on the classpath. Then, QDox is used to add more information (e.g., javadocs). Thus, the build process is like [compile, generate, compile].
This process could be simplified by using QDox to search for factory methods. This way, the classes don't have to be compiled before code generation and the build process is only [generate, compile].
The benefit is a simplified build process (cleaner, faster, easier to set up). Also, it is possible now to use the generated class right in the project.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.