All tests in my test class execute a 'before' method (annotated with JUnit's #Before) before the execution of each test.
I need a particular test not to execute this before method.
Is there a way to do it?
You can do this with a TestRule. You mark the test that you want to skip the before with an annotation of some description, and then, in the apply method in the TestRule, you can test for that annotation and do what you want, something like:
public Statement apply(final Statement base, final Description description) {
return new Statement() {
#Override
public void evaluate() throws Throwable {
if (description.getAnnotation(DontRunBefore.class) == null) {
// run the before method here
}
base.evaluate();
}
};
}
Consider using the #Enclosed runner to allow you to have two inner test classes. One with the required #Before method, the other without.
Enclosed
#RunWith(Enclosed.class)
public class Outer{
public static class Inner1{
#Before public void setup(){}
#Test public void test1(){}
}
public static class Inner2{
// include or not the setup
#Before public void setup2(){}
#Test public void test2(){}
}
}
Unfortunately you have to code this logic. JUnit does not have such feature.
Generally you have 2 solutions:
Just separate test case to 2 test cases: one that contains tests that require "before" running and second that contains tests that do not require this.
Implement your own test running and annotate your test to use it. Create your own annotation #RequiresBefore and mark tests that need this with this annotation. The test runner will parse the annotation and decide whether to run "before" method or not.
The second solution is clearer. The first is simpler. This is up to you to chose one of them.
This question has been asked a while ago, nevertheless, I would like to share my solution:
Annotate the desired method with #Tag("skipBeforeEach")
In your setup() method:
#BeforeEach
void setup(final TestInfo info) {
final Set<String> testTags = info.getTags();
if(testTags.stream()
.filter(tag->tag.equals("skipBeforeEach"))
.findFirst()
.isPresent()){
return;
}
// do your stuff
}```
I was looking for a solution to this problem and bumped into this question. As an update, in JUnit 5 this can be easily accomplished now with the use of the #Nested annotation.
If you are using Mockito, particularly Mockito 3.0, all stubbings will be "strict" and be validated by default.
You could use the Mockito lenient() method.
More here: https://www.baeldung.com/mockito-unnecessary-stubbing-exception#lenient-stubbing
One can also solve this by undoing what was done in #Before setup inside test case.
This is how it may look,
#Before
public void setup() {
TestDataSetupClass.setupTestData();
}
#Test
public void testServiceWithIgnoreCommonSetup() {
TestDataSetupClass.unSet();
//Perform Test
}
There will be pros and cons for solutions here. Minor con for this is, unnecessary cycle of setting and un-setting step. But goes well if one needs to do it for only a test case out of hundreds and avoid overhead of writing self AOP or maintaining multiple inner test classes.
If you have a #After method can clear the work done in #Before, you can manually call the #After method at the begining of your #Test method.
Related
For example, method switchCase(). How do I write test code for it? I can just create 3 different tests just with different values for each test, respective to the switch case value, but I want to try a more efficient way of doing this.
#InjectMocks
private RepoFactory repoFactory;
public void switchCase() {
ConsentApplication consentApplication = repoFactory.getConsentApplicationRepo()
.findOne(consentApplicationVo.getId());
switch (CrestApiServiceNameEnum.getByCode(serviceNameEnum.getCode())) {
case CUST_DATA:
newCrestApiTrack.setRepRefNo(null);
httpHeaders.add("API-KEY", custDataApiKey);
break;
case CREDIT_PARAM:
httpHeaders.add("API-KEY", creditParamApiKey);
break;
case CONFIRM_MUL_ENT:
httpHeaders.add("API-KEY", multiEntitiApiKey);
break;
default:
LOGGER.info("Unexpected value: " + CrestApiServiceNameEnum.getByCode(serviceNameEnum.getCode()));
}
}
What I tried was, using #RunWith(JUnitParamsRunner.class), #ValueSource and #ParameterizedTest. However, this always produces NullPointerException at the first when and java.lang.Exception: Method testSwitchCase_SUCCESS should have no parameters. Can help me on this?
#ParameterizedTest
#ValueSource(strings = {"value1", "value2"})
void testSwitchCase_SUCCESS(String s) {
//have something
when(repoFactory.getConsentApplicationRepo().findOne(anyString()))
.thenReturn(consentApplication);
}
Annotate your test either with #Test or #ParameterizedTest but not both.
From the JUnit 5 documentation:
Parameterized tests make it possible to run a test multiple times with different arguments. They are declared just like regular #Test methods but use the #ParameterizedTest annotation instead.
Also the #RunWith annotation is from JUnit 4. When using JUnit 5 this annotation is unnecessary and should be removed.
Then, as Lesiak has commented: you should separate IO and logic. A method the receives the string to switch on as parameter and returns an object is much easier to test than a method that does everything: read data from the user, operates on it and produce some terminal output.
It seems that you have a mix of JUnit 4 and JUnit 5 annotations. That doesn't really work. If you want to use JUnit 5 then remove all uses of org.junit.Test and org.junit.runner.RunWith from your test class and replace them with org.junit.jupiter.api.Test and org.junit.jupiter.api.extension.ExtendWith.
Fortunately, I found a solution, the class should be annotated with #RunWith(JUnitParamsRunner.class) and #ExtendWith(MockitoExtension.class) and the in setup, we should put initMocks(this);. However, this will only mock a non-static class.
#Before
public void setup() {
initMocks(this);
setupRepos();
setupLoginUser();
setupUserLoginReturn();
setupLoggerAppender();
}
Can you give a simple explanation of #TestInstance annotation and how it is useful in JUnit 5?
I think we can achieve the same effect probably by making our fields static.
I think the docs provide a useful summary:
If you would prefer that JUnit Jupiter execute all test methods on the same test instance, simply annotate your test class with #TestInstance(Lifecycle.PER_CLASS). When using this mode, a new test instance will be created once per test class. Thus, if your test methods rely on state stored in instance variables, you may need to reset that state in #BeforeEach or #AfterEach methods.
The "per-class" mode has some additional benefits over the default "per-method" mode. Specifically, with the "per-class" mode it becomes possible to declare #BeforeAll and #AfterAll on non-static methods as well as on interface default methods. The "per-class" mode therefore also makes it possible to use #BeforeAll and #AfterAll methods in #Nested test classes.
But you've probably read that already and you are correct in thinking that making a field static will have the same effect as declaring the field as an instance variable and using #TestInstance(Lifecycle.PER_CLASS).
So, perhaps the answer to the question "how it could be useful in JUnit 5" is that using a #TestInstance ...
Is explicit about your intentions. It could be assumed that use of the static keyword was accidental whereas use of #TestInstance is less likely to be accidental or a result of thoughless copy-n-paste.
Delegates the responsibility for managing scope and lifecycle and clean up to the framework rather than having to remember to manage that yourself.
This annotation was introduced to reduce the number of objects created when running your unit tests.
Adding #TestInstance(TestInstance.Lifecycle.PER_CLASS) to your test class will avoid that a new instance of your class is created for every test in the class.
This is particulary usefull when you have a lot of tests in the same test class and the instantiation of this class is expensive.
This annotation should be used with caution. All unit tests should be isolated and independent of eachother. If one of the tests changes the state od the test class then you should not use this feature.
Making your fields static to achieve the same effect is not a good idea. It will indeed reduce the number of objects created but they cannot be cleaned up when all tests in the test class are executed. This can cause problems when you have a giant test suite.
#TestInstance is used to configure the lifecycle of test instances for the annotated test class or test interface:
PER_CLASS: A new test instance will be created once per test class.
PER_METHOD: A new test instance will be created for each test method, test factory method, or test template method. This mode is analogous to the behavior found in JUnit versions 1 through 4.
If #TestInstance is not explicitly declared on a test class or on a test interface implemented by a test class, the lifecycle mode will implicitly default to PER_METHOD.
Setting the test instance lifecycle mode to PER_CLASS enables the following features:
Shared test instance state between test methods in a given test class as well as between non-static #BeforeAll and #AfterAll methods in the test class.
Declaration of #BeforeAll and #AfterAll methods in #Nested test classes.
Declaration of #BeforeAll and #AfterAll on interface default methods.
Simplified declaration of #BeforeAll and #AfterAll methods in test classes implemented with the Kotlin programming language.
See the test instance lifecycle documentation for further details.
since no one provide a proper coding example, I would like to give a simple code sample as below to understand the concept,
Per Method Sample - Default Option in Junit5
Note two methods are static, otherwise it will fire an exception because class instantiate in each method.
#TestInstance(Lifecycle.PER_METHOD)
public class MathUtilTestPerMethod {
MathUtil util;
#BeforeAll
static void beforeAllInit() {
System.out.println("running before all");
}
#AfterAll
static void afterAllCleanUp() {
System.out.println("running after all");
}
#BeforeEach
void init() {
util = new MathUtil();
System.out.println("running before each...");
}
#AfterEach
void cleanUp() {
System.out.println("running after each...");
}
#Test
void testSum() {
assertEquals(2, util.addtwoNumbers(1, 1));
}
}
Per Class Sample
Note that static is removed from the two methods and MathUtil object is created globally not in a method, because class instantiate only once.
#TestInstance(Lifecycle.PER_CLASS)
public class MathUtilTestPerClass {
MathUtil util = new MathUtil();
#BeforeAll
void beforeAllInit() {
System.out.println("running before all");
}
#AfterAll
void afterAllCleanUp() {
System.out.println("running after all");
}
#BeforeEach
void init() {
System.out.println("running before each...");
}
#AfterEach
void cleanUp() {
System.out.println("running after each...");
}
#Test
void testSum() {
assertEquals(2, util.addtwoNumbers(1, 1));
}
}
This is also useful when writing tests in Kotlin (because it doesn't have static methods).
So, instead of using a companion object with #JvmStatic funs in it for #BeforeAll or #AfterAll, make the lifecycle PER_CLASS and annotate regular methods with #BeforeAll or #AfterAll:
#TestInstance(TestInstance.Lifecycle.PER_CLASS)
class MyTest {
#BeforeAll
fun setup() {
println("I am invoked only once")
}
}
When using this approach, be careful to reset your instance variables in #BeforeEach or #AfterEach funs if necessary.
Thanks to this article for its help.
We have a cron based job in our application.
The job class is as follows:
public class DailyUpdate implements Job {
public void execute(JobExecutionContext context) throws JobExecutionException {
SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this);
testMethod();
}
private void testMethod()
{
System.out.pritnln("Executed From scheduler");
}
}
How should we write unit test case to test Method
testMethod()
I cannot call testMethod Directly without scheduler as it is private..Any suggestion how to write unit test cases for Scheduler
In order to write a test you need to have an expected behavior so there is no point on testing a method that does nothing.
Now to your main problem. If you have somewhat of a legacy application, and you're not allowed to change the visibility of your methods, the best way to test private methods is to use reflection.
So you can use the following pattern
Method testMethod = DailyUpdate.getDeclaredMethod(testMethod, argClasses);
testMethod .setAccessible(true);
return testMethod.invoke(targetObject, argObjects);
see also this question how to test a class that has private methods fields or inner classes
If you have the opportunity, I would suggest you to use PowerMock (instead of coding it by yourself).
Here is a link explaining how to use it : How to mock private method for testing using PowerMock?
I've developed an application in Java and I'm trying to create unit tests using Powermockito (I should add that I'm new to unit testing).
I have a class called Resource which has a static method called readResources:
public static void readResources(ResourcesElement resourcesElement);
ResourcesElement is also coded by me.
In testing, I want to create my own Resource, so I want the above method to do nothing.
I tried using this code:
PowerMockito.spy(Resource.class);
PowerMockito.doNothing().when(Resource.class, "readResources", Matchers.any(ResourcesElement.class));
The unit test throws an exception:
org.mockito.exceptions.misusing.UnfinishedStubbingException:
Unfinished stubbing detected here:
-> at org.powermock.api.mockito.internal.PowerMockitoCore.doAnswer(PowerMockitoCore.java:36)
Powermockito also suggest that I should use thenReturn or thenThrow after when, but it seems that the method 'when' returns void when it is called after doNothing (which is logical).
If I try:
PowerMockito.when(Resource.class, "readResources", Matchers.any(ResourcesElement.class)).....
doNothing is not an option after when.
I managed to make methods without arguments to do nothing, using the 2 arguments version of the method. For example:
PowerMockito.doNothing().when(Moduler.class, "startProcessing");
This works (startProcessing doesn't take any arguments).
But how can I make methods that do take arguments to do nothing with Powermockito?
You can find a fully functional example below. Since you didn't post the complete example, I can only assume that you did not annotate the test class with #RunWith or #PrepareForTest because the rest seems fine.
#RunWith(PowerMockRunner.class)
#PrepareForTest({Resource.class})
public class MockingTest{
#Test
public void shouldMockVoidStaticMethod() throws Exception {
PowerMockito.spy(Resource.class);
PowerMockito.doNothing().when(Resource.class, "readResources", Mockito.any(String.class));
//no exception heeeeere!
Resource.readResources("whatever");
PowerMockito.verifyStatic();
Resource.readResources("whatever");
}
}
class Resource {
public static void readResources(String someArgument) {
throw new UnsupportedOperationException("meh!");
}
}
Why go through so much trouble just so that your method does not do anything. Just calling PowerMockito.mockStatic(Resource.class) should replace all static methods in your class with default stubs which basically mean they do nothing.
Unless you do want to change the behavior of your method to actually do something just calling PowerMockito.mockStatic(Resource.class) should suffice. Ofcourse this also means all static methods in the class are stubbed which you need to consider.
If doNothing() isn't working you can hack it a bit using the PowerMockito.doAnswer(). This lets you mock into void methods that are supposed to do something, like setting values, etc. If doNothing() doesn't work, using a blank doAnswer() should work fine.
Example:
PowerMockito.doAnswer(new org.mockito.stubbing.Answer<Object>() {
#Override
public Object answer(InvocationOnMock invocation) throws Throwable {
return null; //does nothing
}
}).when(mockObject).methodYouWantToDoNothing(args);
Maybe i can't undestand your question, but i believe it's necessary specify what must do
the method, so if you don't specify thenReturn or thenThrow or whatever powerMockito doesn't know what have to do when read your real code, for example:
REAL CODE:
IPager pag;
IPagerData<List<IDeute>> dpag;
pag = new PagerImpl();
pag.setFiles(nombrefilesPaginador);
pag.setInici(1);
dpag = gptService.obtenirDeutes(idSubjecte, idEns, tipusDeute, periode, pag);
Testing real code by mockito:
IPager pag = new PagerImpl();
pag.setInici(1);
pag.setFiles(0);
when(serveiGpt.obtenirDeutes(eq(331225L),
eq(IConstantsIdentificadors.ID_ENS_BASE),
Matchers.any(ETipusDeute.class),
Matchers.any(EPeriodeDeute.class),
eq(pag)))
.thenThrow(new NullPointerException(" Null!"));
If haven't specify the return my test will be fail.
I hope it helps.
I tried doNothing with different variations but nothing worked except the below solution.
#Before
public void setUp(){
obj = new ClassObj (parameters);
//parameters should also include the class obj for which void method is available
}
I have started testing and now i want to use #After, #Before and #Test but my application only runs the #Before method and gives output on console
before
However, if I remove #After and #Before it runs the #Test. My code is here:
public class TestPractise extends AbstractTransactionalDataSourceSpringContextTests{
#Before
public void runBare(){
System.out.println("before");
}
#Test
public void testingMethod(){
System.out.println("testing");
}
#After
public void setDirty(){
System.out.println("after");
}
}
Why aren't #After, #Test and #before working simultaneously?
Use #BeforeEach instead of #Before and #AfterEach instead of #After.
The AbstractTransactionalDataSourceSpringContextTests class forces the use of the old JUnit 3.x syntax, which means that any of the JUnit 4 annotation will not work.
Your method runBare() is executed not because of the #Before annotation, but because it is named runBare(), which is a method provided by ConditionalTestCase and JUnit TestCase class.
So you have 2 solutions:
Use the AlexR answer to use JUnit 4 tests and Spring;
Keep your inheritance of AbstractTransactionalDataSourceSpringContextTests, but use the onSetUp and onTearDown methods instead of the #Before and #After methods.
Check that you are using Junit4 because from Junit5 onwards #Before/#After is now #BeforeEach/#AfterEach and similalry #BeforeClass/#AfterClass is #AfterAll/#BeforeAll.
It should work... But since you are working with spring framework and JUnit 4 was introduced years ago I's suggest you to use annotations instead of inheritance.
So, annotate you class with #RunWith(SpringJUnit4ClassRunner.class). Remove extends AbstractTransactionalDataSourceSpringContextTests.
Don't forget to make the #Before and #After methods static
Now it should work.
Even if you want to extend Spring abstract test classes at least pay attention that some of them are deprecated. For example class AbstractTransactionalDataSourceSpringContextTests is deprecated.
JUnit Jupiter, aka "JUnit 5": use #BeforeAll
If you use the newer JUnit Jupiter (Java 8 onward), you'll want to replace #Before with #BeforeAll.
Furthermore, you'll need to either annotate your test class with #TestInstance(Lifecycle.PER_CLASS) or make the #BeforeAll method static. Here's an example:
#TestInstance(Lifecycle.PER_CLASS)
class MyTestClass {
MyHeavyResource sharedResource;
#BeforeAll
void init() {
System.out.println("init");
sharedResource = new MyHeavyResource(1234);
}
#Test
void myTest() {
System.out.println("myTest");
sharedResource.methodUnderTest();
}
}
Understanding Lifecycle.PER_CLASS
The likely reason JUnit 5 is more stringent with this -- demanding either static or Lifecycle.PER_CLASS -- is that it wants the test author to acknowledge that any resource instance initialized in a #BeforeAll method will genuinely be shared across each individual unit test method within the class. This could compromise their isolation, for example if the sharedResource in the above example isn't stateless/idempotent.
If sharedResource cannot be safely shared (or if it's reasonably leightweight), the init method should be annotated with #BeforeEach instead, which would create a new instance before executing each individual test within the class.
The Javadoc for TestInstance explain how using Lifecycle.PER_CLASS actually enforces a single instance of the test class; whereas the behaviour of JUnit 4 and earlier was equivalent to Lifecycle.PER_METHOD, which created a new instance of the test class for each #Test method contained therein. This would somewhat mislead the author to suppose that #Before was only executed once for each of those tests.
If you use auto import in an IDE, make sure the #Test and #Before are imported from the org.junit package.
in my case, I had that problem the solution was to change the java access modifier, It was way private.
before (not working)
#Test
void validate() throws Exception {}
after (working)
#Test
public void validate() throws Exception {}