You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using a mocked object, calling a method that is defined in the protocol throws a compile error. Using the Bird protocol that is provided in the example, the BirdMock object should be able to call chirp(volume:).
If this is expected behavior (not being able to call methods on mocked objects), how would a user verify wasCalled() on the method. Wrapping the call in either given or verify still do not produce a success on wasCalled whether it's on the same line, different line, or second call.
I believe the expected behavior is to create the mock object, be able to call the function of a mocked object, then check if that function was called (passing in the exact same parameters) in a verify statement.
In conclusion, wasNeverCalled() seems to always succeed no matter what I tried when working with methods defined in a protocol.
Framework Bugs
Please provide a minimal example of your unit testing code, including any errors.
Expected this to work:
let bird = mock(Bird.self)
bird.chirp(volume: 10)
// 🛑 Ambiguous use of 'chirp(volume:)'
Tried this from documentation:
let bird = mock(Bird.self)
verify(bird.chirp(volume: 50)).wasCalled()
// 🛑 failed - Incorrect total invocations of `chirp(volume: Int) -> Void` matching (50)
expected `0` = 1
wasNeverCalled() always succeeds
let bird = mock(Bird.self)
verify(bird.chirp(volume: 50)) //⚠️ Result of call to 'verify(file:line:_:)' is unused
verify(bird.chirp(volume: 50)).wasNeverCalled()
// ✅
Environment
Mockingbird CLI version (mockingbird version) => 0.6.1
Xcode and macOS version (are you running a beta?) => Xcode 11.0 (11A420a) - Mojave 10.14.5 Beta
Swift version (swift --version) => 5.1
Installation method (CocoaPods, Carthage, from source, etc) => CocoaPods
Unit testing framework (XCTest, Quick + Nimble, etc) => XCTest
Does your project use .mockingbird-ignore? => no
The text was updated successfully, but these errors were encountered:
Verification is for checking whether the mocked object received a certain number of invocations. So you’d need to either directly or indirectly invoke bird.chirp(volume: 50) before calling verify(bird.chirp(volume: 50)).wasCalled(). The tests in MockingbirdTests contain some examples on how to do this.
Alright, so my understanding of how wasCalled() is supposed to operate is slightly wrong. Now that I have implemented a concrete class, Tree, which interacts with a Bird through a BirdMock object, I was able to get the desired results. Just to confirm, mock objects will not be able to call their methods directly? Since they are based directly off the protocol, doing something like bird.chirp(volume: 50) is incorrect. These methods should only be called indirectly by a concrete class, right?
New Issue Checklist
Description
When using a mocked object, calling a method that is defined in the protocol throws a compile error. Using the
Bird
protocol that is provided in the example, theBirdMock
object should be able to callchirp(volume:)
.If this is expected behavior (not being able to call methods on mocked objects), how would a user verify
wasCalled()
on the method. Wrapping the call in eithergiven
orverify
still do not produce a success onwasCalled
whether it's on the same line, different line, or second call.I believe the expected behavior is to create the mock object, be able to call the function of a mocked object, then check if that function was called (passing in the exact same parameters) in a verify statement.
In conclusion,
wasNeverCalled()
seems to always succeed no matter what I tried when working with methods defined in a protocol.Framework Bugs
Please provide a minimal example of your unit testing code, including any errors.
Expected this to work:
Tried this from documentation:
wasNeverCalled()
always succeedsEnvironment
mockingbird version
) => 0.6.1swift --version
) => 5.1.mockingbird-ignore
? => noThe text was updated successfully, but these errors were encountered: