Open GoogleCodeExporter opened 9 years ago
Could be difficult to resolve.
1. I'm assuming no verifications actually work when in this double-proxy case?
2. Is mockito proxy the outer proxy?
3. Wouldn't you prefer to have a simpler test that does not utilize Spring
proxy mechanisms?
Cheers :)
Original comment by szcze...@gmail.com
on 3 Apr 2011 at 11:23
1. It looks like no interactions are recorded on mock/spy in double-proxy case,
so any call to verify() fails and any call to verifyZeroInteractions() always
succeeds regardless of whether mocked/spied methods were called or not.
2. Yes, Mockito is the outer proxy
3. We also have simple traditional unit tests without any Spring stuff.
Here is slightly different use case, let me describe the idea:
- We want to have high-level functional tests, which "view" entire system as a
black box.
- We simulate and verify only "edge" points (DB, JMS, calls to external
subsystems).
- Such tests describe the system from biz perspective, they are very stable and
as a result help during refactoring.
- We verify persistent data in DB directly (JDBC call in the test)
- We use Mockito's spies to verify calls to external API (web services, JMS,
etc.).
- We also use spies to verify that there are no redundant calls to DAOs (proper
caching is in place)
Original comment by itle...@gmail.com
on 4 Apr 2011 at 2:10
Ok i see your point. I wonder if it is possible to reproduce it without spring.
Would you be able to provide us a simple project zip with a test that
reproduces this behavior? This problem may be fixable but there is a chance we
hit cglib limitations.
Original comment by szcze...@gmail.com
on 7 Apr 2011 at 7:57
[deleted comment]
Any progress on this issue. I have similar settings (@Transactional
double-proxy case). But the problem in my case is that the real method is
called during spyied method behaviour configuration with
doAnswer(...).when(spyiedObject).method(any(Type.class));
Any ideas ?
Original comment by Bartosz....@gmail.com
on 20 Sep 2012 at 10:26
Can you provide a self-contained small project that reproduces the problem?
Alternatively, if you can reproduce the behavior in your environment you could
debug into Mockito and submit a patch? :)
Cheers!
Original comment by szcze...@gmail.com
on 20 Sep 2012 at 1:57
I have the same problem with bean that has some method annotated with
@Cacheable.
@Component
public class DemoService {
private static final Logger log = LoggerFactory.getLogger(DemoService.class);
public boolean getTrue() {
log.info("getTrue");
return Boolean.TRUE;
}
@Cacheable("testCache")
public boolean getValueFromCache() {
return true;
}
Why I try to execute:
doReturn(false).when(demoServiceSpy).getTrue();
the getTrue method of DemoService is called and it is not mocked up.
Attached is the sample project.
Original comment by predrag....@gmail.com
on 26 Dec 2012 at 12:09
Attachments:
I also have the same problem with :
@MessageEndpoint
public class RmsStdAlcEndpoint {
@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
public Long processMessage(Message<RmsStdAlc> message) {
//business logic
return 0L;
}
}
when verifing like this in test class:
verify(rmsStdAlcEndpoint).processMessage(Matchers.any(Message.class));
medhod is re-called with null message value so NullPointerException is thrown.
Original comment by bola...@gmail.com
on 30 Jun 2014 at 1:36
Please demonstrate the issue on a simple project, like on github. TIA
Original comment by brice.du...@gmail.com
on 24 Jul 2014 at 6:36
Original issue reported on code.google.com by
itle...@gmail.com
on 31 Mar 2011 at 5:27Attachments: