cloud1105 / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

Clear an intermediate collection affects verify result #419

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

My source code looks like this

final List<SomeType> SomeTypeList = new ArrayList<>();
while (true) {
    transactionTemplateFactory.createTransactionTemplate()
        .execute(new TransactionCallbackWithoutResult() {
            @Override
            protected void doInTransactionWithoutResult(TransactionStatus status) {
                try {
                    SomeTypeList.addAll(someRepository.someMethod());
                } catch (Exception e) {
                    status.setRollbackOnly();
                }
            }
        });
    if (!SomeTypeList.isEmpty()) {
        QueueClass.addInQueue(SomeTypeList);
        SomeTypeList.clear();
    }
}
--------------------------------------------------------------
My test code will try to verify
verify(mockScheduler, times(1)).addInQueue(someList);

What is the expected output? What do you see instead?
without line "SomeTypeList.clear();", my test pass.

with that line, my test failed in

Argument(s) are different! Wanted:
mockQueueClass.addInQueue(
    [someClass@4437a770, someClass@21d1cd0d]
);
Actual invocation has different arguments:
mockQueueClass.addInQueue(
    []
);

What version of the product are you using? On what operating system?
1.9.5

Please provide any additional information below.

Original issue reported on code.google.com by torma2...@gmail.com on 14 Feb 2013 at 5:12

GoogleCodeExporter commented 8 years ago
Hi,

I'm not sure what is the issue here. If you were referring to this line : 
"verify(mockScheduler, times(1)).addInQueue(someList);", this is expected to 
not modify the arguments in a verify step, and it will never do that because it 
makes no sense for a mock framework to infer in such a way with production code.
The code could clean the intermediate state in an After method, or even better 
it should probably get around that issue by tweaking the tests to run in 
isolation of each other (this would be really helpful when JUnit fork mode is 
enabled).

Original comment by brice.du...@gmail.com on 14 Feb 2013 at 2:38

GoogleCodeExporter commented 8 years ago
I'll mark this  issue as invalid, if you feel there is really something wrong 
please report us.

Original comment by brice.du...@gmail.com on 29 Apr 2013 at 4:03