You can capture an argument as follows: // must be declared before when-block (or inside Specification.interaction {}) def captured when: … then: 1 * mock.doNetworkCall(…) >> { record, recordClass -> // save the argument captured = record … } // use the saved argument captured == … That said, often there is a simpler solution … Read more
I think the simple answer is not to use @InjectMocks, and instead to initialise your object directly. The only downside I can see is that you’re not testing the injection, but then with @InjectMocks, I think you’d be testing it with Mockito’s injection implementation, rather than your real framework’s implementation anyway, so no real difference. … Read more
Edit – Mockito 3.7.7 Mockito 3.7.7 unified order of verify parameters (Issue #2173) Updated code: try (MockedStatic<Foo> dummyStatic = Mockito.mockStatic(Foo.class)) { dummyStatic.when(() -> Foo.method(“param1”)) .thenReturn(“someValue”); // when System.out.println(Foo.method(“param1”)); //then dummyStatic.verify( () -> Foo.method(“param1”), times(1), ); } Original answer It is possible, you need to use a lambda instead of a method reference: try (MockedStatic<Foo> dummyStatic … Read more
You can pass null to setMethods() to avoid mocking any methods. Passing an empty array will mock all methods. The latter is the default value for the methods as you’ve found. That being said, I would say the need to do this might point out a flaw in the design of this class. Should this … Read more
Great question. It seems like you hit the limits of Mockito. Mockito is great if what you want to inspect object interactions. What you want, though, seems to be observability (and controllability) at a higher level of abstraction. I’m afraid that the mocks or stubs you need for that should be carefully designed and hand-crafted. … Read more
A mock (no matter if we talk about ordinary objects or beans) is simply an “empty shell”. That mock object doesn’t have any relation to the underlying production code. It is an object that looks like being an object of class X. But none of the methods or fields that X has do “really” exist … Read more
Thanks to those that responded over the last few weeks. I ended up writing a blog post about my findings, since I had to do so much digging that it seemed like I might as well summarize them in the hopes of helping others. The chart I posted organizes my findings: One caveat, which I … Read more
mock.Setup(m => m.CreatePersonName(It.IsAny<PersonName>())) .Returns((PersonName p) => p); Based on: // access invocation arguments when returning a value mock.Setup(x => x.DoSomething(It.IsAny<string>())) .Returns((string s) => s.ToLower()); from https://github.com/Moq/moq4/wiki/Quickstart
There’s a very nice mocking library for Kotlin – Mockk, which allows you to mock objects, the exact same way you’re desiring. As of its documentation: Objects can be transformed to mocks following way: object MockObj { fun add(a: Int, b: Int) = a + b } mockkObject(MockObj) // aplies mocking to an Object assertEquals(3, … Read more
My answer is “no”. You should mock anything that makes sense in the context of a given unit test. It should not matter if you “own” the mocked type or not. These days, in a Java or .NET environment everything (and I really mean everything) can be easily mocked. So, there is no technical reason … Read more