JUnit always creates one instance of the test class for each @Test method. This is a fundamental design decision to make it easier to write tests without side-effects. Good tests do not have any order-of-run dependencies (see F.I.R.S.T) and creating fresh instances of the test class and its instance variables for each test is crucial … Read more
Use maven plugin: <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.7.1</version> <configuration> <parallel>classes</parallel> <threadCount>5</threadCount> </configuration> </plugin> </plugins> </build>
You can do this using Mockito to have the mock return the correct params, verify they were indeed called (optionally specify number of times), write the ‘result’ and verify it’s correct. import static org.junit.Assert.*; import static org.mockito.Mockito.*; import java.io.*; import javax.servlet.http.*; import org.apache.commons.io.FileUtils; import org.junit.Test; public class TestMyServlet extends Mockito{ @Test public void testServlet() throws … Read more
Annotate your util classes with @Ignore. This will cause JUnit not to try and run them as tests.
When you want to use the @Mock annotation you should use the MockitoJUnitRunner @RunWith(MockitoJUnitRunner.class) public class MockitoTest { @Mock private IRoutingObjHttpClient routingClientMock; @Test public void testSendRoutingRequest() throws Exception { // … } } See also this tutorial.
The Slf4j API doesn’t provide such a way but Logback provides a simple solution. You can use ListAppender : a whitebox logback appender where log entries are added in a public List field that we could use to make our assertions. Here is a simple example. Foo class : import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class … Read more
You cannot do this because according to spec you cannot put the same annotation twice on the same annotated element. So, what is the solution? The solution is to put only one @RunWith() with runner you cannot stand without and replace other one with something else. In your case I guess you will remove MockitoJUnitRunner … Read more
I prefer putting the test classes into the same package as the project classes they test, but in a different physical directory, like: myproject/src/com/foo/Bar.java myproject/test/com/foo/BarTest.java In a Maven project it would look like this: myproject/src/main/java/com/foo/Bar.java myproject/src/test/java/com/foo/BarTest.java The main point in this is that my test classes can access (and test!) package-scope classes and members. As … Read more
You need to put the class where the constructor is called into the @PrepareForTest annotation instead of the class which is being constructed – see Mock construction of new objects. In your case: ✗ @PrepareForTest(MyQueryClass.class) ✓ @PrepareForTest(A.class) More general: ✗ @PrepareForTest(NewInstanceClass.class) ✓ @PrepareForTest(ClassThatCreatesTheNewInstance.class)
I’ve used both, but I have to agree with Justin Standard that you shouldn’t really consider rewriting your existing tests to any new format. Regardless of the decision, it is pretty trivial to run both. TestNG strives to be much more configurable than JUnit, but in the end they both work equally well. TestNG has … Read more