devboost / junitloop

JUnitLoop is a tiny Eclipse plug-in that executes all JUnit test cases in the workspace that might be affected when a class is saved.

JUnitLoop

Contains the projects JLoop and JUnitLoop

junitloop's Issues

Typo at the junitloop web home page

Goto http://www.junitloop.org, at "Whenever a code modification results in a test failure, one will immediatedly recognize this" - replace "immediatedly " with "immediately "

Remove tests from LoopTestSuite when containing projects are deleted or closed

To avoid compilation errors in the test suite. Probably, the test should be added again when a project is opened.

Add workspace preference page to exclude projects from JUnitLoop test suite

This is required if one has projects containing long running tests.

JUnitLoop does not install on Eclipse 3.8.2 - dependencies does not match

https://gist.github.com/apolit/5115279

Error trying to install JUnitLoop

The error occurs when trying to install from marketplace / update site / trunk
Windows 7, Java 7b9, Eclipse 4.2.1

The operation cannot be completed. See the details.

Cannot complete the install because one or more required items could not be found.
Software being installed: JUnitLoop 0.6.5.v201210291659 (de.devboost.eclipse.junitloop.feature.group 0.6.5.v201210291659)
Missing requirement: JUnitLoop 0.6.5.v201210291659 (de.devboost.eclipse.junitloop.feature.group 0.6.5.v201210291659) requires 'de.devboost.eclipse.feedback.feature.group 0.0.0' but it could not be found

[JLoop] Allow redirecting output to console window when running in same VM

To do so, we can inject a PrintWriter into a field in the class that runs in the loop.

Classpath Problems with Maven (m2e-Plugin)

We're using Maven in our projects with m2e plugin. Unfortuately this leads in several classpath issues:

• Libs are automaticaly handled by m2e for each project but they are not exported so JUnitLoop project does not inherit this third part dependencies.
• JUnitLoop project has a dependency to JUnit Lib which may not be the same Version as used in our project

Beside this problems (which are unfortuantely not allow to use it) JUniLoop is a very interesting concept that would relly help developers to reduce response time and so improve their work.

Add warning to Problems view when a test fails

As an alternative to keeping the JUnit view open all the time, it would be handy to have notification of test failures show as warnings in the Problems view.

Ideally, the location of the warning (i.e. where you jump to you when you click the warning) should be the top of the stack trace from the test failure. And the description text of the warning should be the exception/error message (e.g. "AssertionError: expected: but was:"). The type of the warning can be something like "Test Failure" for fails and "Test Error" for uncaught throwables.

Test with Eclemma coverage

I have no idea how you'd do this, but if the Eclemma plugin is installed, launch the JUnitLoop test suite in coverage mode.

Given that Eclemma can highlight the code that isn't being covered (with some careful toning down of the annotations and colours it uses, it is not overly distracting or annoying), it would be a great way to get feedback on whether you need to add some more tests.

Include a 'run test suite manually' mode

When the user has a lot of tests in the workspace and the run takes long, the user experience can be improved if JUnitLoop only collects the tests that needs a re-run (i.e. creates the test suite), but does not execute them automatically. Then the user can decide WHEN to run the test but JUnitLoop still decides WHICH tests to run.

A simple toggle button could be introduced to activate this mode.

JUnitLoop doesn't run any tests

I'm still trying to pin this one down, but it is repeatable in my environment:

I have a workspace with many interrelated projects.

1. I turn off "Run in loop" on the JUnit view, and delete the JUnitLoop project (also deleting it from disk).

2. I do a clean and rebuild of the entire workspace.

3. I turn on "Run in loop" on the JUnit view.
   Effect: The JUnitLoop project is recreated with nothing in it.

4. I open a JUnit test case and change something, then save.
   Effect: The log says

   !ENTRY de.devboost.eclipse.jloop 1 0 2014-01-23 07:33:00.752
   !MESSAGE Searching related tests for 1 resource(s).

   And I can see the test I saved in the JUnitLoop project's tests_to_run file, and in the SuiteClasses annotation on LoopTestSuite.
   But no tests are run. I can't see any errors in the log or in the console.
   If I run the LoopTestSuite manually, it works (and the test I saved passes).

This is repeatable in my workspace. But if I create a new workspace to test this out, I cannot reproduce this behaviour. JUnitLoop works perfectly, even if I have multiple projects in the test workspace.

Tests failed for security exception when using jMock expectations

java.lang.SecurityException: class "org.hamcrest.TypeSafeMatcher"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.jmock.internal.InvocationExpectationBuilder.createExpectationFrom(InvocationExpectationBuilder.java:86)
at org.jmock.internal.InvocationToExpectationTranslator.invoke(InvocationToExpectationTranslator.java:19)
at org.jmock.internal.FakeObjectMethods.invoke(FakeObjectMethods.java:38)
at org.jmock.lib.legacy.ClassImposteriser$4.invoke(ClassImposteriser.java:137)
at com.boazlev.tdd.sample.integration.IIntegration$$EnhancerByCGLIB$$1b574d34.doSomething()
at com.boazlev.tdd.sample.basic.CodeTest$2.(CodeTest.java:34)
at com.boazlev.tdd.sample.basic.CodeTest.testResult(CodeTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
at org.jmock.integration.junit4.JMock$1.invoke(JMock.java:37)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:98)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:61)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:54)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:52)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
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:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

JunitLoop uses default JDK instead of project JDK resulting in `java.lang.UnsupportedClassVersionError`

I have multiple JDKs installed. The default JDK is set to Java SE 6, the project JDK is set to Java SE 7 (using Maven). When JUnitLoop runs I stops with

java.lang.UnsupportedClassVersionError: com/acme/MyTest : Unsupported major.minor version 51.0

When I change the default JDK to Java SE 7 everything works as expected.

Expected behavior: JUnitLoop should use the project settings to pick up the JDK.

OSX 10.8.2
Eclipse Juno SR 1, 20121004-1855
JDK (1.6.0_37-b06-434)
JDK (1.7.0_09-b05)

JUnitLoop includes tests that are not in any source folder

I have a few tests that are technically JUnit tests, but cannot be run within Eclipse due to environment dependencies. I want to exclude them from JUnitLoop.

I tried adding @Category(Runtime.class) to them, but it seems JUnit still calls their constructor, which in this case is enough to cause the environment dependency issue and crash JUnit, so none of my other tests get run.

So now I have tried moving those test cases to a folder which is not a source folder (i.e. not included in the build path of the project). However it seems JUnitLoop still includes them in the tests_to_run / LoopTestSuite.java. And since those classes are not on the build path, LoopTestSuite.java fails to compile.

JUnitLoop should only search for JUnit test classes in the source folder(s) of each project.

[JLoop] Add surrounding try/catch to generated runner to correctly handle run() methods that throw exceptions

NullPointerException in JUnitLoop update process (Eclipse Luna upgrade)

Hi, since upgrading (fresh install) to Eclipse Luna, JUnitLoop stopped working; I keep getting this NullPointerException alert in the JUnitLoop (post-build) update process:

Here's info from the associated entry in Eclipse' error log:

Session Data:
eclipse.buildId=4.4.1.M20140925-0400
java.version=1.7.0_71
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments: -product org.eclipse.epp.package.java.product -keyring /Users/amitd/.eclipse_keyring -showlocation
Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.java.product -keyring /Users/amitd/.eclipse_keyring -showlocation

(no stack trace is available)

The JUnitLoop project exists but no source code gets created.

[JLoop] LoopLauncherWrapper code does not compile for runInSameVM()

Although this code is not used by JLoop itself, it should still compile. The code currently tries to call "run()" instead of "runInSameVM()".