In your spec file import the helper this way: import * as helper from ‘./helper’; And in your it() you can spy on the helper object and return the requested value: spyOn(helper, ‘doSomething’).and.returnValue({});
(Update: Mockito has added Android support as of version 1.9.5 and EasyMock has added Android support as of version 3.2 by factoring out those bits that generate code at runtime and making them pluggable, e.g. by using dexmaker instead of cglib.) Except for android-mock mentioned by DixonD (which is a fairly young, unproven library), there … Read more
It should be enough to name your mocks serviceA and serviceB. From Mockito documentation: Property setter injection; mocks will first be resolved by type, then, if there is several property of the same type, by the match of the property name and the mock name. In your example: @InjectMocks ServiceCaller classUnderTest; @Mock SomeService serviceA; @Mock … Read more
You should use Moq to create your Mock object and set CallBase property to true to use the object behavior. From the Moq documentation: CallBase is defined as “Invoke base class implementation if no expectation overrides the member. This is called “Partial Mock”. It allows to mock certain part of a class without having to … Read more
You can use SimpleNamingContextBuilder to make a jndi datasource available to your tests: SimpleNamingContextBuilder builder = new SimpleNamingContextBuilder(); builder.bind(“java:comp/env/jdbc/mydatasource”, dataSource); builder.activate(); https://fisheye.springsource.org/browse/spring-framework/spring-test/src/main/java/org/springframework/mock/jndi/SimpleNamingContextBuilder.java?hb=true This isn’t exactly mocking the datasource, but it does make the datasource available via jndi for your tests.
Yes, you use instance methods. Static methods basically say, “There is one way to accomplish this functionality – it’s not polymorphic.” Mocking relies on polymorphism. Now, if your static methods logically don’t care about what implementation you’re using, they might be able to take the interfaces as parameters, or perhaps work without interacting with state … 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
C++ Unit Testing With Boost.Test (permanent link: http://web.archive.org/web/20160524135412/http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/) The above is a brilliant article and better than the actual Boost documentation. Edit: I also wrote a Perl script which will auto-generate the makefile and project skeleton from a list of class names, including both the “all-in-one” test suite and a stand alone test suite for … 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