Allow mocking of static methods #97
Comments
moltmann
added a commit
to moltmann/dexmaker
that referenced
this issue
Apr 7, 2018
Similar to stubbing of instance methods this uses an JVMTI agent to add a
method entry hook to all affected methods. This change adds a new JVMTI
agent that is only used for stubbing of static methods. This comes with
its own mockMaker that hooks into the multiplexer added in a previous
change.
Most aspects of stubbing static methods are quite similar to instance
methods. Here are the differences:
== Scope of mocking ==
For instance methods the methods stay stubbed until the object goes
away. For static methods there is no object. Hence from the user point
of view the scope is defined by a MockitoSession. Internally we use a
marker object to track all stubbing of static methods for a class.
We use ThreadLocal variables to communicate between the frontEnd i.e.
ExtendedMockito and the backend i.e. InlineStaticMockMaker.
== Highlander rule for static mocking ===
As we set up mocking/spying per class, we can only mock/spy a class once
per session.
== 'inherited' static methods ==
In the following case:
---
class SuperClass {
static String returnA() { return "A"; }
}
class SubClass {
}
@test
public void test() {
SubClass.returnA();
}
---
The backtraces actually contains SuperClass.returnA(). We have to look
at the byte code of the calling method to figure out if the method was
called on the super or subclass. While this is _super_expensive_ (~10ms
in my unscientific experiments) I see no other way.
|
Pull 98 covers step 1 - 3 of above agenda |
drewhannay
pushed a commit
that referenced
this issue
Apr 21, 2018
Similar to stubbing of instance methods this uses an JVMTI agent to add a
method entry hook to all affected methods. This change adds a new JVMTI
agent that is only used for stubbing of static methods. This comes with
its own mockMaker that hooks into the multiplexer added in a previous
change.
Most aspects of stubbing static methods are quite similar to instance
methods. Here are the differences:
== Scope of mocking ==
For instance methods the methods stay stubbed until the object goes
away. For static methods there is no object. Hence from the user point
of view the scope is defined by a MockitoSession. Internally we use a
marker object to track all stubbing of static methods for a class.
We use ThreadLocal variables to communicate between the frontEnd i.e.
ExtendedMockito and the backend i.e. InlineStaticMockMaker.
== Highlander rule for static mocking ===
As we set up mocking/spying per class, we can only mock/spy a class once
per session.
== 'inherited' static methods ==
In the following case:
---
class SuperClass {
static String returnA() { return "A"; }
}
class SubClass {
}
@test
public void test() {
SubClass.returnA();
}
---
The backtraces actually contains SuperClass.returnA(). We have to look
at the byte code of the calling method to figure out if the method was
called on the super or subclass. While this is _super_expensive_ (~10ms
in my unscientific experiments) I see no other way.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@mockitoguy, @drewhannay
The Android API uses static methods, e.g. in Settings.Global . Some tests might want to mock those.
In mockito/mockito#1013 there is a discussion for adding that to mockito. Unfortunately it might take some time to get this into mockito as we need
Hence I am proposing to prototype this as a variant of dexmaker-mockito-inline. Once this has proved useful we can upstream it to mockito.
I propose the following agena:
The text was updated successfully, but these errors were encountered: