If an example contains two or more expectations, and the subject of one of the verifiers is nil, the verifier following will produce an NSInternalInconsistencyException ("Trying to add another verifier without specifying a matcher for the previous one.") instead of reporting a verification failure. If this verifier is the last in the example, Kiwi reports the failure correctly.
I have not yet dug into this, but I'm guessing this has to do with the mechanism that Kiwi uses to try to guard against losing verifiers as a result of the "should" message being sent to a nil subject (which simply eats the message). I expect the verifier is setting a flag somewhere that gets read at the end of the example, to complete any "unfinished" expectations. However, if another verifier comes after the one that had a nil subject, it instead runs into the unfinished expectation.
Perhaps this could be fixed by having the verifier initialization code perform the same check that seems to be happening at the end of an example, so that it can identify the problem correctly, and differentiate if from a real unfinished specification.
If an example contains two or more expectations, and the subject of one of the verifiers is nil, the verifier following will produce an NSInternalInconsistencyException ("Trying to add another verifier without specifying a matcher for the previous one.") instead of reporting a verification failure. If this verifier is the last in the example, Kiwi reports the failure correctly.
I have not yet dug into this, but I'm guessing this has to do with the mechanism that Kiwi uses to try to guard against losing verifiers as a result of the "should" message being sent to a nil subject (which simply eats the message). I expect the verifier is setting a flag somewhere that gets read at the end of the example, to complete any "unfinished" expectations. However, if another verifier comes after the one that had a nil subject, it instead runs into the unfinished expectation.
Perhaps this could be fixed by having the verifier initialization code perform the same check that seems to be happening at the end of an example, so that it can identify the problem correctly, and differentiate if from a real unfinished specification.