I have the following code:
public void someMethod() {
Set<Foo> fooSet = bar.getFoos();
for(Foo foo: fooSet) {
foo.doSomething();
}
}
and I want to test this using JMockit but am unsure how to get to return a collection of a certain type and size.
The following test for my code throws a null pointer exception for hashcode when trying to add foo to the set of foos.
#Test
public void someTestMethod()
{
new Expectations()
{
#Mocked Bar bar;
#Mocked Foo foo;
Set<Foo> foos = new HashSet<Foo>();
foos.add(foo);
bar.getFoos(); returns(foos);
foo.doSomething();
};
new SomeClass().someMethod();
}
How should this be done?
I'm not exactly sure how to answer your question because I don't understand what you are trying to test, but I believe you want something like this:
#Test
public void someTestMethod(#Mocked(methods="getFoos")final Bar mockedBar
#Mocked(methods="doSomething")final Foo mockedFoo {
final Set<Foo> foos = new HashSet<Foo>();
foos.add(new Foo());
new Expectations() {
{
mockedBar.getFoos(); returns(foos);
mockedFoo.doSomething();
}
};
new SomeClass().someMethod();
}
Using this, JMockit will mock the call to getFoos and return the Set foos. If you look at the parameters I am passing in, I am doing a partial mock of the Bar and Foo classes (I am only mocking the calls to the getFoos and doSomething method). I also noticed you are missing a set of braces in your new Expectations block, so that could definitely cause you some problems. One other issue you have to keep in mind is that using Expectations as opposed to NonStrictExpectations will cause an error if you put more than one object in the Set foos because it is only expecting one call to doSomething. If you make a test case where foos has more than one object in it you could either use NonStrictExpectations or use the minTimes and maxTimes to specify invocation count constraints
Related
Here's a simplified version of what I want to test with Mockito:
class UnderTest {
fun doSomething() {
foo.doAnything()
}
}
class Foo {
fun doAnything(bar: Bar = Bar())
}
class TestUnderTest {
#Mock
var underTest: UnderTest
#Test
fun testDoSomething() {
underTest.doSomething() // Causes NPE
}
}
UnderTest is being tested. Its dependencies, like foo, are mocked. However, when my tests call UnderTest.doSomething(), it crashes. doSomething() calls Foo.doAnything(), letting it fill in the null parameter with the default - and the code that runs in that default parameter initialization is outside of the control of my test, as it's inside the static, synthetic method created for the byte code.
Is there a magical Mockito solution to get around this very situation? If so, I would love to hear it. Otherwise, I believe the options I have are:
To use PowerMock or Mockk to be able to mock things Mockito can't
To change Foo to have two doAnything() methods; one would have zero parameters, would call Bar() and pass it to the other.
To change Foo.doAnything() to accept a nullable parameter, then to have the body of the function call Bar() and use it.
I have been learning Kotlin and have come across the concept of open properties. Coming from C++, the concept of "open" makes sense, and extending that logic to properties does as well. However, I can't think of any case where an open val/var is actually necessary or useful. I understand when they make sense for interfaces, but not concrete classes. Furthermore, overriding getters/setters makes sense, but not redefining the property with a new backing field. For example, say you have this kind of class structure:
open class Foo {
open var str = "Hello"
}
class Bar : Foo() {
override var str = "world"
init {
println(str)
println(super.str) // Shows that Bar actually contains "hello" and "world"
}
}
To me, it would seem to be a far better design to make Foo take str as a constructor argument, for instance:
open class Foo(var str = "Hello") // Maybe make a secondary constructor
class Bar : Foo("world") // Bar has only 1 string
This is both more concise, and seems to often be a better design. This is also the way it tends to be done in C++, so maybe I just don't see the benefit of the other way. The only possible time I can see overriding a val/var with a new one is if it for some reason needs to use super's value, like in
override val foo = super.foo * 2
Which still seems pretty contrived.
When have you found this useful? Does it allow for greater efficiency or ease of use?
open fields let you re-define getter and setter methods. It's practically pointless if you just return constants. However altering getter / setter behavior has (infinite) potential, so I'll just throw some ideas:
// propagate get/set to parent class
class Bar : Foo() {
override var str
get() = super.str.toUpperCase()
set(value) {
super.str = value
}
}
// creates a backing field for this property
class Bar : Foo() {
override var str = "World"
get() = field.toLowerCase()
// no need to define custom set if we don't need it in this case
// set(value) { field = value }
}
// instead of writing custom get/set, you can also use delegates
class Bar : Foo() {
override var str by Delegates.observable("world"){ prop, old, new ->
println("${prop.name} changed from $old to $new")
}
}
What is the difference between these two as per Mockito -
Mockito.when(serviceObject.myMethod(Customer.class)).thenThrow(new
RuntimeException());
and
Customer customer = new Customer();
Mockito.when(serviceObject.myMethod(customer)).thenThrow(new
RuntimeException());
And if both serve the same purpose then using which one is considered to be best practice?
There is a misunderstanding on your side - that method specification myMethod(SomeClass.class) is only possible when the signature of that method allows for a class parameter. Like:
Whatever myMethod(Object o) {
or directly
Whatever myMethod(Class<X> clazz) {
In other words: it is not Mockito that does something special about a parameter that happens to be of class Class!
Thus your first option is not something that works "in general". Example: I put down this code in a unit test:
static class Inner {
public int foo(String s) { return 5; }
}
#Test
public void testInner() {
Inner mocked = mock(Inner.class);
when(mocked.foo(Object.class)).thenReturn(4);
System.out.println(mocked.foo(""));
}
And guess what - the above does not compile. Because foo() doesn't allow for a Class parameter. We can rewrite to
static class Inner {
public int foo(Object o) { return 5; }
}
#Test
public void testInner() {
Inner mocked = mock(Inner.class);
when(mocked.foo(Object.class)).thenReturn(4);
System.out.println(mocked.foo(""));
}
And now the above compiles - but prints 0 (zero) when invoked. Because the above would be the same as mocked.foo(eq(Object.class)). In other words: when your method signature allows for passing a Class instance and you then pass a class instance, that is a simple mocking specification for mockito. In my example: when the incoming object would be Object.class - then 4 would be returned. But the incoming object is "" - therefore the Mockito default kicks in and 0 is returned.
I am with the other answer here - I think you are mixing up that older versions of Mockito asked you to write down when(mocked.foo(any(ExpectedClass.class))) - which can nowadays be written as when(mocked.foo(any())). But when(mocked.foo(ExpectedClass.class)) is not a Mockito construct - it is a simple method specification that gives a specific object to "match on" - and that specific object happens to be an instance of class Class.
First one which uses generic Customer class to match type can also be written as:
Mockito.when(serviceObject.myMethod(Mockito.any(Customer.class))).thenThrow(new
RuntimeException());
In case of the second one, you are passing the actual object that will be used in stubbing.
Usage:
If your method myMethod throws the exception based on the state of the Customer object then you can use the latter approach, where you can set the state of the Customer object appropriately.
However If your method myMethod does not depend on the Customer object to throw the exception rather you need it only to pass it as an argument just to invoke the method, then you can take the former approach.
I have this code base which is rather big ( +/- 500k lines). I'm looking in it to find all the method calls that use a single parameter and that parameter is a specific type.
This means, I want to be able to find method calls like the following:
public class Foo { }
public class Bar { }
public class Doer{
public void doSomethingFoo(Foo foo) { }
public void doSomethingObject(Object object) { }
}
public class Usage {
Doer doer = new Doer();
public doSomething() {
Foo anObject = new Foo();
Bar bar = new Bar();
doer.doSomethingFoo(anObject);
doer.doSomethingObject(anObject);
doer.doSomethingObject(bar);
}
}
Since both doer.doSomethingFoo(anObject) and doer.doSomethingObject(anObject) are called, both those statements should be returned by the search. Similarly, doer.doSomethingObject(bar) is not returned. Of course, I don't know that doer exists.
I'm trying to use the Structural Search of IntelliJ to do so. I've used the following template $Instance$.$Method$($Parameter$), with the following parameters:
$Instance$ -> Text/regexp = .*
$Method$ -> Text/regexp = .*
$Parameter$ -> Text/regexp = Foo
Minimum count = 1 // Minimum one Foo parameter
Maximum count = 1 // Maximum one Foo parameter
This returns everything that has a parameter named foo (case-insensitive, apparently). So I'm probably doing something wrong here. But what? How can I get all calls to any method where the only param is of type Foo?
You are almost there. All you need to do now is set the Expression type (regexp) of $Parameter$ to Foo and leave Text/regexp blank. Additionally you may want to enable the Apply constraint within type hierarchy checkbox, to find subclasses of Foo too.
Note that you can leave the Text/regexp of all variables blank. This is equivalent to .*.
I'm trying to understand why the following code throws:
open class Base(open val input: String) {
lateinit var derived: String
init {
derived = input.toUpperCase() // throws!
}
}
class Sub(override val input: String) : Base(input)
When invoking this code like this:
println(Sub("test").derived)
it throws an exception, because at the time toUpperCase is called, input resolves to null. I find this counter intuitive: I pass a non-null value to the primary constructor, yet in the init block of the super class it resolves to null?
I think I have a vague idea of what might be going on: since input serves both as a constructor argument as well as a property, the assignment internally calls this.input, but this isn't fully initialized yet. It's really odd: in the IntelliJ debugger, input resolves normally (to the value "test"), but as soon as I invoke the expression evaluation window and inspect input manually, it's suddenly null.
Assuming this is expected behavior, what do you recommend to do instead, i.e. when one needs to initialize fields derived from properties of the same class?
UPDATE:
I've posted two even more concise code snippets that illustrate where the confusion stems from:
https://gist.github.com/mttkay/9fbb0ddf72f471465afc
https://gist.github.com/mttkay/5dc9bde1006b70e1e8ba
The original example is equivalent to the following Java program:
class Base {
private String input;
private String derived;
Base(String input) {
this.input = input;
this.derived = getInput().toUpperCase(); // Initializes derived by calling an overridden method
}
public String getInput() {
return input;
}
}
class Derived extends Base {
private String input;
public Derived(String input) {
super(input); // Calls the superclass constructor, which tries to initialize derived
this.input = input; // Initializes the subclass field
}
#Override
public String getInput() {
return input; // Returns the value of the subclass field
}
}
The getInput() method is overridden in the Sub class, so the code calls Sub.getInput(). At this time, the constructor of the Sub class has not executed, so the backing field holding the value of Sub.input is still null. This is not a bug in Kotlin; you can easily run into the same problem in pure Java code.
The fix is to not override the property. (I've seen your comment, but this doesn't really explain why you think you need to override it.)
The confusion comes from the fact that you created two storages for the input value (fields in JVM). One is in base class, one in derived. When you are reading input value in base class, it calls virtual getInput method under the hood. getInput is overridden in derived class to return its own stored value, which is not initialised before base constructor is called. This is typical "virtual call in constructor" problem.
If you change derived class to actually use property of super type, everything is fine again.
class Sub(input: String) : Base(input) {
override val input : String
get() = super.input
}