which is clearly a mistake because the return will never actually be used. Even worse you can have:
OCMReject([stub foo]).andThrow(anException)
which essentially is the same as OCMStub().andThrow but doesn't appear that way to the reader.
I am attempting to cut down on the myriad of ways that you can use OCMock wrong, and have seen multiple examples of what appeared to be a refactor where an expect got changed to a reject, but the .and was not cleaned up.
I can see some possible functionality with something like:
OCMReject([stub foo].andCall()
but I think you could duplicate all of this functionality using OCMStub (and dealing with the rejected state in the call) so that it makes sense to disallow actions on rejects.
So right now you can have things like:
OCMReject([stub foo]).andReturn(@"blah")which is clearly a mistake because the return will never actually be used. Even worse you can have:
OCMReject([stub foo]).andThrow(anException)which essentially is the same as
OCMStub().andThrowbut doesn't appear that way to the reader.I am attempting to cut down on the myriad of ways that you can use OCMock wrong, and have seen multiple examples of what appeared to be a refactor where an expect got changed to a reject, but the
.andwas not cleaned up.I can see some possible functionality with something like:
OCMReject([stub foo].andCall()but I think you could duplicate all of this functionality using OCMStub (and dealing with the rejected state in the call) so that it makes sense to disallow actions on rejects.
Thoughts?