take a look to junit 4.4 theories: import org.junit.Test; import org.junit.experimental.theories.*; import org.junit.runner.RunWith; @RunWith(Theories.class) public class PrimeTest { @Theory public void isPrime(int candidate) { // called with candidate=1, candidate=2, etc etc } public static @DataPoints int[] candidates = {1, 2, 3, 4, 5}; }
@Test(expected = Exception.class) Tells Junit that exception is the expected result so test will be passed (marked as green) when exception is thrown. For @Test Junit will consider test as failed if exception is thrown, provided it’s an unchecked exception. If the exception is checked it won’t compile and you will need to use other … Read more
Take a look at Parameterized Tests in JUnit 4. Actually I did this a few days ago. I’ll try to explain … First build your test class normally, as you where just testing with one input file. Decorate your class with: @RunWith(Parameterized.class) Build one constructor that takes the input that will change in every test … Read more
All these answers seem overkill. You don’t add tests to make a metric tool happy. Loading a Spring context of the application takes time. Don’t add it in each developer build just to win about 0.1% of coverage in your application. Here you don’t cover only 1 statement from 1 public method. It represents nothing … Read more
This worked out for me. I’m only using JUnit and I was able to mock up the Log class without any third party lib very easy. Just create a file Log.java inside app/src/test/java/android/util with contents: package android.util; public class Log { public static int d(String tag, String msg) { System.out.println(“DEBUG: ” + tag + “: … Read more
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
Had the same message. I had to remove the Run/Debug configuration. In my case, I ran the unit test as a local test before. After that I moved my test to the androidTest package and tried to run it again. Android Studio remembered the last run configuration so it tried to run it again as … Read more
The old method (of JUnit 3) was to mark the test-classes by extending junit.framework.TestCase. That inherited junit.framework.Assert itself and your test class gained the ability to call the assert methods this way. Since version 4 of JUnit, the framework uses Annotations for marking tests. So you no longer need to extend TestCase. But that means, … Read more
The error is most likely caused by declaring the AuthenticationManager as a @Bean. Try this in your test class: @MockBean private AuthenticationManager _authenticationManager; That said, the Spring Security team does not recommend exposing the AuthenticationManager in this way, see the comment in Spring issue #29215
For this case I have created the derby-maven-plugin. It’s available from Maven Central, so you don’t need to add any extra repositories or anything. You could use it like this: <project …> <build> <plugins> <plugin> <groupId>org.carlspring.maven</groupId> <artifactId>derby-maven-plugin</artifactId> <version>1.8</version> <configuration> <basedir>${project.build.directory}/derby</basedir> <port>1527</port> </configuration> <executions> <execution> <id>start-derby</id> <phase>pre-integration-test</phase> <goals> <goal>start</goal> </goals> </execution> <execution> <id>stop-derby</id> <phase>post-integration-test</phase> <goals> <goal>stop</goal> … Read more