Marcio Garcia

The point here is not to discuss if using static methods is good or not. If you prefer just to use dependency injection and pure object orientation instead of static methods, that’s with you.
However sometimes you have to live with code not made by you.
You can see this as “Such nasty code, thanks good the project is almost finishing and I’ll no longer see this code anymore!”
Did you noted the tense? “Almost finishing” it’s not done yet and it’ll depend of you to finish it.
Or you can have a different approach - that’s my favourite:
“This code suchs! Let’s do something better and learn something with that.”

Starting…

That’s the start point:
I have a code with some static methods and I have to test the code that use these static methods from outside classes.

Environment

The environment is: Java, Maven, JUnit4, Mockito and PowerMock (when the magic happens)

Pom.xml

Some configuration is necessary to make use of Powermock:

Pay attention on the version of your Mockito/JUnit/Powermock it’s a bit tricky.

Static file

The static file looks like this:

The piece of code that calls the FileHelper.saveFile(..) is this one:

Testing

Take a look at the code that’s gonna test the Controller…

Important

- Two new annotations on the class level:
@RunWith(PowerMockRunner.class)
@PrepareForTest(FileHelper.class) : Tells to PowerMock what is the class that shoud be static mocked.
- PowerMockito.mockStatic(StaticClass.class) : mocks the class

Let’s start from begin: What is the difference between Object and Data Structure?

From wikipedia a Data Structure is: a data structure is a particular way of storing and organizing data in a computer so that it can be used efficiently.[1][2]

As well as Object is: any entity that can be manipulated by the commands of a programming language, such as a value (computer science), variable, function, or data structure.

Just to put some code in it.

This is a Data Structure:

And this is an Object:

This is how I’m policing myself to code. Letting VOs, DTOs, Entities exactly as a data structure, just with fields, getters and setters. Even constructors I am letting outside it. Maybe I’m exaggerating do not creating the constructors or switching them to static methods into the VOs. However, my experience with this approach tells me that letting them out is more productive specially when we are talking about testable code and isolating responsibilities improving the Single Responsibility Principle.

You may be asking: “Are telling that I’m not more able to create my own Entities directly?

The answer is yes and no. I’ll explain.

To a simple task just create an instance of an Data Structure, you could just call the default constructor.
But to create a more sophisticated instance of that object for some specific porpoise instead of using a static method describing the usage of that as suggested by Uncle Bob Martin on his book Clean Code I suggest you to use an Object to handle the creation of the Data Structure initializing it with the propers values for the specific usage.

Do you disagree? Let your comment down here!

To test private methods in Java is tough. I’ve faced developments model who instead of let methods as private the developers were forced to assign as default to be testable. Off course it is just a work around with a few collateral effects.

This is the class with the private method:

1
2
3
4
5
6
7
8
9
10
11

package com.marciogarcia;
 
public class SomeBean {
 
	private static final int FACTOR = 2;
 
	private int executeSomeTask(int val1, int val2) {
		int returnValue = (val1 + val2) * FACTOR;
		return returnValue;
	}
}

That’s a sample of what could be done keeping the method private and using just Java and reflection:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package com.marciogarcia.test;
 
import static org.junit.Assert.assertEquals;
 
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import org.junit.Test;
import com.marciogarcia.SomeBean;
 
public class SomeBeanJTest {
 
	@Test
	public void test_Execute_Some_Test_With_Java() {
		int value = 0;
		try {
			Method m = SomeBean.class.getDeclaredMethod("executeSomeTask", int.class, int.class);
			m.setAccessible(true);
			value = ((Integer) m.invoke(new SomeBean(), 1, 2)).intValue();
		} catch (NoSuchMethodException nsme) {
			System.out.println(nsme.toString());
		} catch (InvocationTargetException ite) {
			System.out.println(ite.toString());
		} catch (IllegalAccessException iae) {
			System.out.println(iae.toString());
		}
		assertEquals(6, value);
	}
}

Now, that’s what could be done keeping the method private and adding Groovy as a test solution.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package com.marciogarcia.test
 
import static org.junit.Assert.assertEquals;
import org.junit.Test;
import com.marciogarcia.SomeBean;
 
public class SomeBeanGTest{
 
	@Test
	public void test_Execute_Some_Test_With_Groovy() {
		int value = new SomeBean().executeSomeTask(1, 2);
		assertEquals(6, value);
	}
}

Groovy simple ignore private methods, actually it is using underneath reflection to execute the task to call the method. This is a bug, but it is extremely useful that it is considered a “feature” instead of a bug.