I want in my multi-moduled project to have integration tests using JUnit and TestNG containers. Is it possible to do that without this error:
Multiple TestRunners found, only one allowed. Check your classpath
I get this error when I have together below dependencies for
arquillian-junit-container
arquillian-testng-container
Related
My project is a webapplication, currently I have deployed it my local machine. I have some testcases written in Mockito, Junit.
When I run the Junit test on the whole project, by right clicking on project , all these test cases run successfully but when I pick up an individual test case and run it I get the below error and test case wont run.
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object
I have all the required jars of mockito and junit.
I have a project that creates a bean library and is built upon spring boot. In the latest spring tools suite (eclipse), I have a set of junit test cases that stands up a spring boot server and tests those beans. All tests are passing. I heard about the EclEmma eclipse plugin so I installed it. I left the defaults and just ran 'Coverage As' > 'JUnit Test' just like I can successfully run 'Run As' > 'JUnit Test', but the coverage is failing with
IllegalStateException: Failed to load ApplicationContext
I checked the classpath and it matches the successful JUnit runas because it's the same run as configuration. Can anyone help me?
Spring boot project, there is a web integration test, when execute it in eclipse (run as > junit test) it's ok.
public class ReservationControllerIntegrationTest extends BaseWebIntegrationTest{...}
but when run mvn clean package , encountered below error:
initializationError(com.foo.web.BaseWebIntegrationTest) Time elapsed: 0.005 sec <<< ERROR!
java.lang.Exception: No runnable methods
at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:191)
at org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:128)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:416)
at org.junit.runners.ParentRunner.<init>(ParentRunner.java:84)
at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:65)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.<init>(SpringJUnit4ClassRunner.java:140)
when I changed
public class BaseWebIntegrationTest
to
public abstract class BaseWebIntegrationTest
then run mvn clean package again, this time it is build successfully!
So why run junit test in eclipse do not need to specify abstract explicitly?
The mvn surefire plugin auto-detects test suites based on some simple rules applied to all the classes it finds under src/main/test. In particular, it looks for all concrete classes matching a particular naming convention.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html
In your case the plugin thinks that BaseWebIntegrationTest is a test suite, because it matches the naming convention, but it's not finding any test methods in it. When you made the class abstract the plugin skipped it because it was no longer instantiable. You could also have renamed the class so that it didn't end in the word Test.
When you run the test in Eclipse I'm guessing you run the specific integration test (ReservationControllerIntegrationTest) and so Eclipse doesn't try to treat BaseWebIntegrationTest as a test suite.
I am using the JUnit for code coverage in my project. For db i am using the dbunit as like mock DB. When i am running JUnit from Eclipse UI its getting passed, but its getting failed when run through maven.
Above set up is running fine in JDK 1.6.25 by using maven and its started failing when upgraded to 1.8.51. I had updated the maven compiler plugin, its doesn't work. I am used below versions, junit - 4.7 2.dbunit - 2.4.8 hsqldb - 2.0.0 maven - 2.2.1.
Issue:
-> All test cases which ran fine in JAVA 1.6, started failing on migrating to JDK 1.8.51.
-> Due this we faced build failure issue and also code coverage reduction.
Root Cause:
-> JUnit uses Java reflection to get the test methods from Test classes. In JAVA 1.6 test method order returned as same as declaration in source file.
-> But from JAVA 7 onwards the methods order returned the by JVM is not same as the source file, it will be returned randomly.
-> Since our test cases are dependent on each other, due to order change it started failing.
For Example below test cases are using the same data (Mock DB) for execution,
-> AddOperationTestCase()
-> EditOperationTestCase()
-> DeleteOperationTestCase()
If delete run first due JVM random order, for Add and Edit data won't be available it will fail.
Solution :
-> I had tried to find options in JUnit and Sure Fire plugin to maintain same order as like source file, but I could not find feasibility there.
-> I have identified the class which will returns the order of execution in JUnit library and override that accordingly to run it source file order.
-> As of now I had added this annotation wrapper to failed classes, now build is running successfully.
Link for Wrapper class:
https://somethingididnotknow.wordpress.com/2014/03/07/run-junit-tests-in-order/
If a bundle throws an exception in osgi, the stack-trace is printed on the osgi console. I want to be notified if a bundle throws an exception. I thought using osgi logging service could help about it. However I could not get it to work under Helios.
The question is how can I be notified if a bundle throws an exception in osgi Helios.
Or if osgi logging does the work, how can I get osgi logging to work in Helios? As much as I googled, there is apparently no implementation of osgi loggin service currently integrated in helios. I downloaded the equinox skd 3.6 from eclipse site that contains the bundle org.eclipse.equinox.log, however I could add it as dependency to my plugins, or install it in the osgi runtime.
Any help is really appreciated.
A bundle can only throw an exception when it is invoked. This nearly always when some other bundle invoked one of your published services, or because the bundle received a callback from the framework such as BundleActivator.start().
In the first case, OSGi has absolutely no way to know that an exception happened! Service invocations are direct method calls between two objects, and are not brokered or proxied by the OSGi framework. Therefore if you want to find out about the exception, you must catch it in the calling code.
In the second case, callbacks happen because some bundle caused them to happen. For example, a bundle will be started because some other bundle called Bundle.start(). In this case, an exception thrown from the BundleActivator.start() method would be wrapped in a BundleException that could be caught by the calling code.
So it's really all down to your code, unless you have some third-party bundles that invoke your services or start/stop your bundles (e.g. a web console, or a shell like GoGo). In this case it's down to the third party code. In most cases they should send messages to the LogService, so you should install the log bundle into your framework.
You said that you couldn't install the log bundle, but you didn't say why it failed, what the error message was etc! This kind if information is important if you want help resolving the problem.
You could try Pax Logging and a custom Log4J appender - Pax Logging provides implementations of the OSGi LogService etc as well as wrappers for common logging frameworks.
Do you want to do this purely to log/notify exceptions, or is there some other reason? An UncaughtExceptionHandler might be what you want if it's a case of managing your own or wrapped code.