How to use possiblyExpectingExceptions method of org.junit.runners.BlockJUnit4Runner class

As of JUnit 4.12 (unreleased at time of writing), it will be possible to annotate a single static rule with both @Rule and @ClassRule.

Note that it must be static - a non-static rule annotated with @Rule and @ClassRule is still considered invalid (as anything annotated @ClassRule works at the class level, so only really makes sense as a static member).

See the release notes and my pull request if you're interested in more detail.

Not sure this will solve your problem but GlassFish Embedded provides a Java EE 6 implementation. Add this to your pom.xml:

<project>
  ...
  <repositories>
    <repository>
      <id>glassfish-extras-repository</id>
      <url>http://download.java.net/maven/glassfish/org/glassfish/extras</url>
    </repository>
  </repositories>
  ...
  <dependencies>
    <dependency>
      <groupId>org.glassfish.extras</groupId>
      <artifactId>glassfish-embedded-all</artifactId>
      <version>3.0.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>javax</groupId>
      <artifactId>javaee-api</artifactId>
      <version>6.0</version>
      <scope>provided</scope>
    </dependency>
    ...
  </dependencies>
  ...
</project>

It's important to declare the glassfish-embedded-all artifact before the javaee-api.

At first you should check your test logic. Usually there are 3 cases. First, you are mocking the wrong method (you made a typo or someone changed tested code so that mocked method is no longer used). Second, your test is failing before this method is called. Third, your logic falls in wrong if/switch branch somewhere in the code so that mocked method is not called.

If this is the first case you always want to change the mocked method for the one used in the code. With the second and the third it depends. Usually you should just delete this mock if it has no use. But sometimes there are certain cases in parametrized tests, which should take this different path or fail earlier. Then you can split this test into two or more separate ones but that's not always good looking. 3 test methods with possibly 3 arguments providers can make your test look unreadable. In that case for JUnit 4 you silent this exception with either

@RunWith(MockitoJUnitRunner.Silent.class) 

annotation or if you are using rule approach

@Rule
public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.LENIENT);

or (the same behaviour)

@Rule
public MockitoRule rule = MockitoJUnit.rule().silent();

For JUnit 5 tests you can silence this exception using this annotation provided in mockito-junit-jupiter package:

@ExtendWith(MockitoExtension.class)
@MockitoSettings(strictness = Strictness.LENIENT)
class JUnit5MockitoTest {
}

Sping 3.0 introduced RestTemplate. Since version 3.2, the Spring MVC test framework has provided the class MockRestServiceServer for unit testing client REST code.

Stubbing

You'll need a test double (stub) to allow isolated, easy, unit testing. The following is non tested, but demonstrates the idea. The use of Dependency Injection will allow you to inject at test time, a test version of your HttpURLConnection.

public class MyClass() 
{
   private IHttpURLConnection httpUrlConnection;   

   public MyClass(IHttpURLConnection httpUrlConnection)
   {
       this.httpUrlConnection = httpUrlConnection;
   }

   public String pushEvent(Event event) 
   {
       String url = constructURL(event);
       String response = callWebsite(url);
       return response;
  }
}

Then you create a stub (sometimes referred to as a mock object) to be the stand in for the concrete instance.

class TestHttpURLConnection : IHttpURLConnection { /* Methods */ }

You'll also construct a concrete version, for your production code to use.

class MyHttpURLConnection : IHttpURLConnection { /* Methods */ }

Using your test class (an adapter) you are able to specifiy what should happen during your test. A mocking framework will enable you to do this with less code, or you can manually wire this up. The end result of this for your test is that you'll set your expectations for your test, for example, in this case you may set OpenConnection to return a true boolean (This is just an example by the way). Your test will then assert that when this value is true, the return value of your PushEvent method matches some expected result. I've not touched Java properly for a while, but here are some recommended mocking frameworks as specified by StackOverflow members.

This feature is builtin since Mockito 1.9.5. Just use

mock(ClassToMock.class, withSettings().verboseLogging())

The library System Lambda has a method withEnvironmentVariable for setting environment variables.

import static com.github.stefanbirkner.systemlambda.SystemLambda.*;

public void EnvironmentVariablesTest {
  @Test
  public void setEnvironmentVariable() {
    String value = withEnvironmentVariable("name", "value")
      .execute(() -> System.getenv("name"));
    assertEquals("value", value);
  }
}

For Java 5 to 7 the library System Rules has a JUnit rule called EnvironmentVariables.

import org.junit.contrib.java.lang.system.EnvironmentVariables;

public class EnvironmentVariablesTest {
  @Rule
  public final EnvironmentVariables environmentVariables
    = new EnvironmentVariables();

  @Test
  public void setEnvironmentVariable() {
    environmentVariables.set("name", "value");
    assertEquals("value", System.getenv("name"));
  }
}

Full disclosure: I'm the author of both libraries.

this just happened to me. Rebuilding or restarting Eclipse didn't help.

I solved it by renaming one of the test methods to start with "test..." (JUnit3 style) and then all tests are found. I renamed it back to what it was previously, and it still works.

How about Thread.sleep(2000); ? :)