Basically, you are going down the very wrong rabbit hole here. It is not a good idea to throw together so many things.
First of all, Mockito (and all the other mocking frameworks) are intended to be used for behavior, not state. In other words. Albeit your mock object actually has that field, keep in mind: it still is a mock object. You won't find much documentation or tutorials telling you what the mocking framework will do about fields, and field values of mocked objects.
Worse, and the real problem: you do not mock your class under test. You use mocks to gain control over other objects that your code under test is using. Mocking and testing the same object simply does not make (much) sense!
Then: do not use reflection together with "mocking" based unit testing, especially not to "reflect" on mocked objects. As said: these frameworks do whatever they think is necessary, so even if some code works today, there is a realistic chance that a new version of Mockito might change such internals, and cause such code to fail in the future.
Next, note that your code is nonsensical to begin with:
public final String VALUE= "ABC";
public String someMethod(){
if (!VALUE.equals("ABC")){ ## IF NOT WORKING
VALUE is always ABC, so you always end up with if(!true)
. There is no point in having that if statement in your code then.
So, if you really need such kind of a switch, you could make it a method call, like:
public String someMethod(){
if (reallyDoIt())) ...
with
boolean reallyDoIt() { return ...
The point is: now you could use Mockito's spy concept to test your someMethod()
call. By doing so, you can instruct Mockito to "really" call someMethod()
but to return a fake answer for reallyDoIt()
. For more details, see here for example.
Beyond that, I strongly recommend that you step back and read a good tutorial about Mockito, like the one from vogella. Simply because your code implies that you do not really understand how to use mocking frameworks in unit testing.