I am using Hamcrest Matchers to check if two beans have same property Values. It is working fine in Eclipse but fails when I run using cmd. Following is the stack trace for the same. Can anyone please help?
java.lang.NoSuchFieldError: NONE
at org.hamcrest.DiagnosingMatcher.matches(DiagnosingMatcher.java:12)
at org.hamcrest.beans.SamePropertyValuesAs.hasMatchingValues(SamePropertyValuesAs.java:63)
at org.hamcrest.beans.SamePropertyValuesAs.matchesSafely(SamePropertyValuesAs.java:31)
at org.hamcrest.TypeSafeDiagnosingMatcher.matches(TypeSafeDiagnosingMatcher.java:55)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
My code is as follows:
assertThat(actualBean, samePropertyValuesAs(expectedBean));
Related
Im getting the following error in my quarkus app, but only in integration tests, when the tests are running as part of the maven build and not when running the tests within my IDE (or when running in dev mode).
java.util.ServiceConfigurationError:
org.eclipse.microprofile.context.spi.ThreadContextProvider:
io.quarkus.arc.runtime.context.ArcContextProvider not a subtype
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1236)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1383)
at java.base/java.lang.Iterable.forEach(Iterable.java:74)
at io.smallrye.context.SmallRyeContextManager$Builder.discoverThreadContextProviders(SmallRyeContextManager.java:293)
at io.smallrye.context.SmallRyeContextManager$Builder.build(SmallRyeContextManager.java:333)
at io.smallrye.context.SmallRyeContextManagerProvider.getContextManager(SmallRyeContextManagerProvider.java:48)
at io.smallrye.context.SmallRyeContextManagerProvider.getContextManager(SmallRyeContextManagerProvider.java:37)
at io.smallrye.context.SmallRyeContextManagerProvider.getManager(SmallRyeContextManagerProvider.java:97)
at io.smallrye.context.SmallRyeThreadContext.getCurrentThreadContextOrDefaultContexts(SmallRyeThreadContext.java:160)
at io.smallrye.mutiny.context.DefaultContextPropagationInterceptor.getThreadContext(DefaultContextPropagationInterceptor.java:12)
at io.smallrye.mutiny.context.BaseContextPropagationInterceptor.decorate(BaseContextPropagationInterceptor.java:82)
at io.smallrye.mutiny.infrastructure.Infrastructure.decorate(Infrastructure.java:226)
at io.smallrye.mutiny.groups.UniOnItem.transform(UniOnItem.java:115)
at io.smallrye.mutiny.Uni.map(Uni.java:384)
at ...
This looks like some classloading issue but having a debugger in the build shows that the loaded ThreadContextProvider is assignable from the loaded ArcContextProvider, Is there anything else I should be looking for here? A bit stumped.
My groovy file contains:
#Grapes([
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.7'),
#Grab('org.apache.httpcomponents:httpmime:4.5.1')
])
.......code
I am trying to compile groovy and java code. But I am getting below error:
java.lang.RuntimeException: Transform groovy.grape.GrabAnnotationTransformation#69bda33a cannot be run
This works for me, note that I did change HttpBuilder to v.0.7.1:
#Grapes([
#Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.7.1'),
#Grab(group='org.apache.httpcomponents', module='httpmime', version='4.5.1')
])
Likely way too late for you to care, but I saw the same error just now.
I suspect the problem is that the #Grab annotation can't take effect because Maven is controlling the dependencies, or perhaps because Maven is trying to compile both Groovy and Java code, and the class loader created by the #Grab annotation can't influence the Java code.
Upshot is, I suspect you (and I) need to move the dependency out of the Groovy class in question, and put it into the pom.xml file Maven is using.
I have a RESTful service created using Spring MVC. I created an integration test to test my Rest controller, using spring-test mvcmock.
When I am running this test using run as Junit. It is running fine.
However, when the same test is getting executed during mvn install, using surefire plugin. This test is complaining throwing fatal error:
No qualifying bean of type ...
When I checked previous logs it says that it loaded 0 dependecy.
This was the log :
DEBUG XmlBeanDefinitionReader - Loaded 0 bean definitions from location pattern [classpath*:service-test-context.xml]
However, I again run this test class as Junit and I could see "loaded 23 beans at the same log line."
Question: Could you please suggest, what can be the issue?
Note:
This is multi maven module application and dependency of another module is not getting injected.
I was getting same issue, when I was running this test as Junit. Then I added dependent modules in eclipse > build > project and issue got resolved in run as JUnit. Now getting this issue while doing mvn install.
Does your surefire configuration contain an includes parameter?
"A list of elements specifying the tests (by pattern) that should be included in testing. When not specified and when the test parameter is not specified, the default includes will be
<includes>
<include>**/Test*.java</include>
<include>**/*Test.java</include>
<include>**/*TestCase.java</include>
</includes>
"
Easy fix is to rename your test runner so that it ends in Test.java. Then
mvn test
will pick it up.
Updated
An alternative is this:
"test:
Specify this parameter to run individual tests by file name, overriding the includes/excludes parameters. Each pattern you specify here will be used to create an include pattern formatted like **/${test}.java, so you can just type "-Dtest=MyTest" to run a single test called "foo/MyTest.java". The test patterns prefixed with a ! will be excluded.
This parameter overrides the includes/excludes parameters, and the TestNG suiteXmlFiles parameter. Since 2.7.3, you can execute a limited number of methods in the test by adding #myMethod or #my*ethod. For example, "-Dtest=MyTest#myMethod". This is supported for junit 4.x and testNg.
Since 2.19 a complex syntax is supported in one parameter (JUnit 4, JUnit 4.7+, TestNG):
"-Dtest=???Test, !Unstable*, pkg/**/Ci*leTest.java, Test#testOne+testTwo?????, #fast*+slowTest"
"-Dtest=Basic*, !%regex[..Unstable.], !%regex[..MyTest.class#one.|two.], %regex[#fast.|slow.*]"
The Parameterized JUnit runner describes test methods using an index in brackets, so the non-regex method pattern would become: #testMethod[]. If using #Parameters(name="{index}: fib({0})={1}") and selecting the index e.g. 5 in pattern, the non-regex method pattern would become #testMethod[5:].
Type: java.lang.String
Required: No
User Property: test
"
So if your test runner was named foo/MyVeryOwnRunner.java you could do the following
mvn clean test -Dtest=MyVeryOwnRunner
I wrote a unit test that passes when I run it in Eclipse, but fails when I do "maven install".
I use JUnit 4, Mockito 1.9.5, Maven 3.0.4, JRE 1.7._51, Sunfire 2.15.
The assert that seemingly fails is:
assert string1.equals(string2);
Answer
Java keyword assert must be activated to work.
They can be activated at run-time by way of the -ea option on the java command, but are not turned on by default.
What does the Java assert keyword do, and when should it be used?
Some advices
For string comparision use equals
assert string1.equals(string2)
How do I compare strings in Java?
Use junit assertions in test
assertEquals(string1, string2)
assert vs. JUnit Assertions
For best results use AssertJ - Fluent assertions for java
assertThat(string1).isEqualTo(string2);
Does anyone know how to enableassertions during testing? I'm trying to use buildr to for a lucene based project and I get the following exception:
[junit] Test class requires enabled assertions, enable globally (-ea) or for Solr/Lucene subpackages only:
I've tried from the command line:
JAVA_OPTS=-ea buildr
and putting the following in my buildfile:
ENV['JAVA_OPTS'] ||= '-enableAssertions'
I'm using the java version of buildr (1.4.12)
ugh, 2 seconds after submitting this I figured out the solution:
test.using :java_args => [ '-ea' ]
I had same issue with SOLR and eclipse, solution is exactly the same.
In package explorer right click on project:
Run As->Run Configurations...->JUnit->ProjectName->Arguments(second tab)->VM arguments
Type in :-ea