Develop Reference

Mockito mocks locally final class but fails in Jenkins

I have written some unit tests for a static method. The static method takes only one argument. The argument's type is a final class. In terms of code:
public class Utility {
public static Optional<String> getName(Customer customer) {
// method's body.
}
}
public final class Customer {
// class definition
}
So for the Utility class I have created a test class UtilityTests in which I have written tests for this method, getName. The unit testing framework is TestNG and the mocking library that is used is Mockito. So a typical test has the following structure:
public class UtilityTests {
#Test
public void getNameTest() {
// Arrange
Customer customerMock = Mockito.mock(Customer.class);
Mockito.when(...).thenReturn(...);
// Act
Optional<String> name = Utility.getName(customerMock);
// Assert
Assert.assertTrue(...);
}
}
What is the problem ?
Whereas the tests run successfully locally, inside IntelliJ, they fail on Jenkins (when I push my code in the remote branch, a build is triggered and unit tests run at the end). The error message is sth like the following:
org.mockito.exceptions.base.MockitoException: Cannot mock/spy class
com.packagename.Customer Mockito
cannot mock/spy because :
- final class
What I tried ?
I searched a bit, in order to find a solution but I didn't make it. I note here that I am not allowed to change the fact that Customer is a final class. In addition to this, I would like if possible to not change it's design at all (e.g. creating an interface, that would hold the methods that I want to mock and state that the Customer class implements that interface, as correctly Jose pointed out in his comment). The thing that I tried is the second option mentioned at mockito-final. Despite the fact that this fixed the problem, it brake some other unit tests :(, that cannot be fixed in none apparent way.
Questions
So here are the two questions I have:
How that is possible in the first place ? Shouldn't the test fail both locally and in Jenkins ?
How this can be fixed based in the constraints I mentioned above ?
Thanks in advance for any help.

An alternative approach would be to use the 'method to class' pattern.
Move the methods out of the customer class into another class/classes, say CustomerSomething eg/CustomerFinances (or whatever it's responsibility is).
Add a constructor to Customer.
Now you don't need to mock Customer, just the CustomerSomething class! You may not need to mock that either if it has no external dependencies.
Here's a good blog on the topic: https://simpleprogrammer.com/back-to-basics-mock-eliminating-patterns/

How that is possible in the first place? Shouldn't the test fail both locally and in Jenkins ?
It's obviously a kind of env-specifics. The only question is - how to determine the cause of difference.
I'd suggest you to check org.mockito.internal.util.MockUtil#typeMockabilityOf method and compare, what mockMaker is actually used in both environments and why.
If mockMaker is the same - compare loaded classes IDE-Client vs Jenkins-Client - do they have any difference on the time of test execution.
How this can be fixed based in the constraints I mentioned above?
The following code is written in assumption of OpenJDK 12 and Mockito 2.28.2, but I believe you can adjust it to any actually used version.
public class UtilityTest {
#Rule
public InlineMocksRule inlineMocksRule = new InlineMocksRule();
#Rule
public MockitoRule mockitoRule = MockitoJUnit.rule();
#Test
public void testFinalClass() {
// Given
String testName = "Ainz Ooal Gown";
Client client = Mockito.mock(Client.class);
Mockito.when(client.getName()).thenReturn(testName);
// When
String name = Utility.getName(client).orElseThrow();
// Then
assertEquals(testName, name);
}
static final class Client {
final String getName() {
return "text";
}
}
static final class Utility {
static Optional<String> getName(Client client) {
return Optional.ofNullable(client).map(Client::getName);
}
}
}
With a separate rule for inline mocks:
import org.junit.rules.TestRule;
import org.junit.runner.Description;
import org.junit.runners.model.Statement;
import org.mockito.internal.configuration.plugins.Plugins;
import org.mockito.internal.util.MockUtil;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
public class InlineMocksRule implements TestRule {
private static Field MOCK_MAKER_FIELD;
static {
try {
MethodHandles.Lookup lookup = MethodHandles.privateLookupIn(Field.class, MethodHandles.lookup());
VarHandle modifiers = lookup.findVarHandle(Field.class, "modifiers", int.class);
MOCK_MAKER_FIELD = MockUtil.class.getDeclaredField("mockMaker");
MOCK_MAKER_FIELD.setAccessible(true);
int mods = MOCK_MAKER_FIELD.getModifiers();
if (Modifier.isFinal(mods)) {
modifiers.set(MOCK_MAKER_FIELD, mods & ~Modifier.FINAL);
}
} catch (IllegalAccessException | NoSuchFieldException ex) {
throw new RuntimeException(ex);
}
}
#Override
public Statement apply(Statement base, Description description) {
return new Statement() {
#Override
public void evaluate() throws Throwable {
Object oldMaker = MOCK_MAKER_FIELD.get(null);
MOCK_MAKER_FIELD.set(null, Plugins.getPlugins().getInlineMockMaker());
try {
base.evaluate();
} finally {
MOCK_MAKER_FIELD.set(null, oldMaker);
}
}
};
}
}

Make sure you run the test with the same arguments. Check if your intellij run configurations match the jenkins. https://www.jetbrains.com/help/idea/creating-and-editing-run-debug-configurations.html. You can try to run test on local machine with the same arguments as on jenkins(from terminal), if it will fail that means the problem is in arguments

JUnit does not seem to be invoking my overridden TestWatcher failed/succeeded methods

Note: The code for MyTest has been updated to reflect the answer I found, which is caused by multiple implementations of assertEquals() being available in JUnit's ecosystem.
I've seen a similar question in C, but no answer/responses. I've either taken a left turn on the implementation, or am overlooking something simple. So...
I'd expect to see the "IT FAILED" and "IT PASSED" on the console, but no joy. Just the "testFailure()" and "testSuccess()" output.
TestRunner impl
import junit.runner.Version; // added to support version check
import org.junit.runner.JUnitCore;
public class TestRunner {
public static void main(String[] args) {
System.out.println(Version.id()); // added to check JUnit version
JUnitCore.runClasses(MyTest.class);
}
}
Test impl
// NO LONGER NEDED (v3 -v- v4) import junit.framework.TestCase;
import org.junit.Rule;
import org.junit.Test;
import ort.junit.Assert.assertEquals; // version that invokes TestWatcher
// public class MyTest extends TestCase { // JUnit v3.X semantics
public class MyTest { // JUnit v4.X semantics
#Rule
public MyTestWatcher myTestWatcher = new MyTestWatcher();
#Test
public void testFailure() {
System.out.println("testFailure()");
assertEquals("failure", true, false);
}
#Test
public void testSuccess() {
System.out.println("testSuccess()");
assertEquals("failure", true, true);
}
}
TestWatcher impl
import org.junit.rules.TestWatcher;
import org.junit.runner.Description;
public class MyTestWatcher extends TestWatcher {
public MyTestWatcher() {}
#Override
protected void failed(Throwable e, Description description) {
System.out.println("IT FAILED");
}
#Override
protected void succeeded(Description description) {
System.out.println("IT PASSED");
}
}

The root cause is the backwards compatibility between JUnit v3.X and JUnit v4.X. It's nice, but it injected an interesting overload on the assertion statements.
In my original code, the method being invoked was org.junit.framework.TestCase.assertEquals(). However, this version of assertEquals() does not seem to invoke TestWatcher.failed() and TestWatcher.succeeded(). So, while the code "ran successfully", it did not output the desired logging information (i.e., "IT FAILED"/"IT PASSED").
The solution was to make sure that the assert statements are invoking the correct implementation (i.e., those in org.junit.Assert). The simplest way to do this was to modify the test to conform to v4.X semantics (i.e., not extend TestCase), and then add the correct import statement.
With these modifications to MyTest, everything now works as expected. I have updated my original post to show where modifications were made.

How can I use strings to describe test cases in Java?

With JUnit, the description of my test cases would normally in the method name, like:
#Test
public void should_return_6_if_distance_is_2km() {
}
or
#Test
public void shouldReturn6IfDistanceIs2km() {
}
Which is not quite readable.
But with the testing frameworks of other lanuage, like javascript, or scala, I can use:
describe("Taximeter") {
it("should return 6 if the distance is 2km") {
...
}
}
which is more readable with plain strings.
Is it possible to do this in Java?

Using a good Assertion Framework, like Hamcrest, AssertJ or Truth will automatically result in better error messages at least. And of course, the assertions themselves will be much more readable than just using assertTrue, assertEquals, etc.
For example, AssertJ:
assertThat( myVar ).describedAs( "myVar" ).isEqualTo( 6 );
This will result in an error message (if myVar != 6) that includes the name "myVar", the expected value and the real value.

Spectrum is quite close to my requirement:
#RunWith(Spectrum.class)
public class ExampleSpec {{
describe("A spec", () -> {
final int foo = 1;
it("is just a code block with a run() method", new Block() {
#Override
public void run() throws Throwable {
assertEquals(1, foo);
}
});
it("can also be a lambda function, which is a lot prettier", () -> {
assertEquals(1, foo);
});
it("can use any assertion library you like", () -> {
org.junit.Assert.assertEquals(1, foo);
org.hamcrest.MatcherAssert.assertThat(true, is(true));
});
describe("nested inside a second describe", () -> {
final int bar = 1;
it("can reference both scopes as needed", () -> {
assertThat(bar, is(equalTo(foo)));
});
});
it("can have `it`s and `describe`s in any order", () -> {
assertThat(foo, is(1));
});
});
}

The assert methods in JUnit allow you to do something similar. You could do something like:
assertTrue("Should return 6 if the distance is 2km but returned " + myvar, myvar == 6);
This allows your code to be readable but only returns a message if the expected condition isn't met.

Not sure about the Scala-Part, is this just a Description or runnable Testcode?
If Description:
For readable but automateable Testcase-Descriptions check out
cucumber (https://cucumber.io) or jBehave (http://jbehave.org)
If runnable Code:
To try to make the code of the Testcase itself more readable hamcrest (https://code.google.com/p/hamcrest/wiki/Tutorial) could be an option.

You have to write your own Runner for this and use it with #RunWith.

I have been wondering the same thing for a long time. The closest I have found to the "describe"-"it" way of organizing tests is the NestedRunner. Check it out here
It is not the same and has some limitations, but definitely an improvement.
Just saw the link OP posted - Spectrum is even better! I am definitely trying it out asap. Thanks for sharing :)

Unit tests written with Mockito framework are pretty readable. The docs promise the ability to “write beautiful tests” that are “more readable” and “produce clean verification errors.” See for yourself:
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;
import static org.junit.Assert.assertThat;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
import static org.mockito.Mockito.eq;
#RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {
#Mock
private UserRepository userRepositoryMock;
#InjectMocks
private UserService userService = new UserService();
#Test
public void testLoadUserByUsername() {
// Expected objects
User demoUser = new User("user", "demo", "ROLE_USER");
// Mockito expectations
when(userRepositoryMock.findByUsername("user")).thenReturn(demoUser);
// Execute the method being tested
User userDetails = userService.loadUserByUsername("user");
// Validation
assertThat(userDetails.getUsername(), eq("user"));
verify(userRepositoryMock).findByUsername("user");
}
}
To have Mockito available with Maven the following dependency should be used:
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.8.47</version>
<scope>test</scope>
</dependency>
And to have Mockito available with Gradle the following dependency should be used:
dependencies { testCompile "org.mockito:mockito-core:2.+" }

Recursively call system while mocking

I've been trying for a while to mock my codes. I'm newby on mocking so lots of things ahead of me to catch. I'm using Powermockito with Mockito and Easymock integration.
I'm having difficulties with mocking a method which is inside the method I wanted to test. So here is an example of the situation I faced:
public class trialClass {
public static int try2(){
return 3;
}
public static int try(int a){
return try2() + a;
}
}
and my test class is:
#RunWith(PowerMockRunner.class)
#PrepareForTest(trial.class)
public class trialTest {
#Before
public void setUp() throws Exception {
PowerMockito.mockStatic(trial.class);
//Here I expect try2() to return 10, even it return 3
PowerMockito.when(trial.try2()).thenReturn(10);
}
#Test
public void testtry() throws Exception {
//After try2() returns 10 recursively inside my try() method,
//I expect result to be 11
Assert.assertEquals(11, trial.try(1));
}
}
This question of mine actually comes from my session variable. My session holds some value and an X method returns that value. All I need is to mock that X method recursively and this question just simulates this case.
Thanks for your help guys.

You need to use Mockito.CALLS_REAL_METHODS
So in your test setup:
PowerMockito.mockStatic(trial.class, CALLS_REAL_METHODS);

EDIT
It occurred to me that you might not want to change to EasyMock instead of Mockito, in that case please disregard...
Partial mocking is the keyword you are after. You don't want to mock everything, just try2(). You should use the PowerMock.mockStaticPartial(Class, String...) method.
Instead of
PowerMockito.mockStatic(trialClass.class);
Use
PowerMock.mockStaticPartial(trialClass.class, "try2");
And then do the actual mocking.
Also note that you defined the clas as trialClass in the code above, but use trial.class in the second code...

Please find an updated version of your TrialTest.java using EasyMock with PowerMock as a solution. PowerMock is easy to configure and does not interfere with most existing jars. You only need a few JARS
powermock-easymock-X.X.X-full.jar
Easymock-X.X.jar
You had some issues with your code that I fixed:
Code Issue: try is a Java keyword so it cannot be used in method name (e.g., try(int a)).
Code Quality: Use Java Object instead of Java primitive (e.g., Use Integer instead of int).
Code Quality: trialClass is a poor Java class name (e.g., Use upperCase for Java class name, don't use the generic word Class unless for educational purposes), maybe Trial.
Here's the updated code:
Trial.java (CUT)
public class Trial {
public static Integer try2() {
return 3;
}
public static Integer try1(int a) {
return try2() + a;
}
}
Working Test Class: TrialTest.java
import org.easymock.EasyMock;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.api.easymock.PowerMock;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
#RunWith(PowerMockRunner.class)
#PrepareForTest(Trial.class)
public class TrialTest {
#Before
public void setUp() throws Exception {
/* Setup */
PowerMock.mockStaticPartial(Trial.class, "try2");
/* Mocks */
// Here I expect try2() to return 10, even it return 3
EasyMock.expect(Trial.try2()).andReturn(10).atLeastOnce();
PowerMock.replayAll();
}
#Test
public void testtry() throws Exception {
// After try2() returns 10 recursively inside my try() method,
// I expect result to be 11
/* Test */
Integer result = Trial.try1(1);
/* Asserts */
PowerMock.verifyAll();
Assert.assertEquals(new Integer(11), result);
}
}

Mock Runtime.getRuntime()?

Can anyone make any suggestions about how best to use EasyMock to expect a call to Runtime.getRuntime().exec(xxx)?
I could move the call into a method in another class that implements an interface, but would rather not in an ideal world.
interface RuntimeWrapper {
ProcessWrapper execute(String command) throws IOException;
}
interface ProcessWrapper {
int waitFor() throws InterruptedException;
}
I was wondering if anyone had any other suggestions?

Your class shouldn't call Runtime.getRuntime(). it should expect a Runtime to be set as its dependency, and work with it. Then in your test you can easily provide a mock and set it as a dependency.
As a sidenote, I'd suggest watching this lecture on OO Design for testability.
Update: I didn't see the private constructor. You can try using java bytecode instrumentation in order to add another constructor or make the constructor public, but that might turn out to be impossible as well (if there are some restrictions on that class).
So your option is to make a wrapper (as you suggested in the question), and follow the dependency-injection approach.

Bozho above is IMO the Correct Solution. But it is not the only solution. You could use PowerMock or JMockIt.
Using PowerMock:
package playtest;
public class UsesRuntime {
public void run() throws Exception {
Runtime rt = Runtime.getRuntime();
rt.exec("notepad");
}
}
package playtest;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.legacy.PowerMockRunner;
import static org.powermock.api.easymock.PowerMock.*;
import static org.easymock.EasyMock.expect;
#RunWith(PowerMockRunner.class)
#PrepareForTest( { UsesRuntime.class })
public class TestUsesRuntime {
#Test
public void test() throws Exception {
mockStatic(Runtime.class);
Runtime mockedRuntime = createMock(Runtime.class);
expect(Runtime.getRuntime()).andReturn(mockedRuntime);
expect(mockedRuntime.exec("notepad")).andReturn(null);
replay(Runtime.class, mockedRuntime);
UsesRuntime sut = new UsesRuntime();
sut.run();
}
}

Perhaps instead of mocking Runtime.getRuntime().exec() you could "mock" the script/program/etc. it's supposed to be calling.
Instead of passing the real command-line string into exec(), write a test script and execute it instead. You could have the script return hard-coded values you could test against just like a mocked class.

Here is how you would do it with EasyMock 3.0 (and JUnit 4):
import org.junit.*;
import org.easymock.*;
import static org.easymock.EasyMock.*;
public final class EasyMockTest extends EasyMockSupport
{
#Test
public void mockRuntimeExec() throws Exception
{
Runtime r = createNiceMock(Runtime.class);
expect(r.exec("command")).andReturn(null);
replayAll();
// In tested code:
r.exec("command");
verifyAll();
}
}
The only problem with the test above is that the Runtime object needs to be passed to code under test, which prevents it from using Runtime.getRuntime().
With JMockit, on the other hand, the following test can be written, avoiding that problem:
import org.junit.*;
import mockit.*;
public final class JMockitTest
{
#Test
public void mockRuntimeExec() throws Exception
{
final Runtime r = Runtime.getRuntime();
new NonStrictExpectations(r) {{ r.exec("command"); times = 1; }};
// In tested code:
Runtime.getRuntime().exec("command");
}
}