barum / gomock

Automatically exported from code.google.com/p/gomock
Apache License 2.0
0 stars 0 forks source link

False positives when using Times(0) on Call #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
We're using Times(0) to expect a call _NOT_ to be made.

To reproduce the problem, create a mock and a method. Test some code and expect 
a method not to be called within that code.
We used a call similar like this: mock.EXPECT().myMethod(Any()).Times(0)

I expected to get an error because an expectation didn't match but instead I 
don't see anything. And all the test are good/green so we get a false positive.

We're using the master branch at SHA: f465e13c1a71273ab234f1e40a327556b6518a27

We've been looking around and we suspect the exhausted should be check in 
controller finish aswel like you do for satisfied.

if !call.satisfied() {
    ctrl.t.Errorf("missing call(s) to %v", call)
    failures = true
} else if call.exhausted() {
    ctrl.t.Errorf("too many call(s) to %v", call)
    failures = true
}

This doesn't solve the problem completely though. You could also say Times(0) 
isn't supported and make the Times method more defensive and don't accept 0 as 
a valid parameter. But we would like to solve it instead :D

Original issue reported on code.google.com by ni...@kabisa.nl on 1 May 2014 at 8:35

GoogleCodeExporter commented 9 years ago
Yeah, it looks like (*Controller).Call does not deal with exhausted calls until 
a call is actually matched. I think this would be solved by skipping exhausted 
calls in callSet.FindMatch.

Original comment by dsymo...@golang.org on 7 Jul 2014 at 12:19

GoogleCodeExporter commented 9 years ago
This issue was closed by revision 5d0b59c9f277.

Original comment by dsymo...@golang.org on 7 Jul 2014 at 12:27