Please do correct me if I'm phrasing the question poorly.
Assume the following code:
class Filters
def self.good ducks
ducks.select(&:good)
end
end
Is it possible to write a test that does not simply construct a bunch of different arrays with combinations of duck mocks (i.e. none/one/some/many with combinations of good/non-good) and then asserts that an array of the correct mocks are returned? It seems to me that it should be possible to simply say that the ducks
array (or rather argument) is expected to receive the message select
with the method good
as a block (please correct me if I'm using incorrect terminology). Similar to how we e.g. can say expect(obj).to receive(:foo).with(:bar)
.
The example may seem to trivial so to avoid arguments saying that it is a useless method and that the user of the method instead simply should call select
, please consider the fact that moving the select
-statement simply moves the need for the test to another location.
Further, in case you want to argue that I am trying to test the implementation rather than the behavior, I would agree, but I would also argue that it in this case is what I want to test.
Enumerating all of the cases (of course not actually all but none/one/some/many for combinations of true/false good
states) makes me feel that I am in fact not unit testing the method but integration testing it since I'm letting knowledge of the behavior of select
"leak" into my good
method causing the number of test cases to multiply.
If I were to unit test the method, it seems to me that I should only be testing the cases (1) not array, (2) non-empty array, and depending on what I'm delegating to (in this case select
) probably also (3) empty array.
Am I misunderstanding or overlooking something fundamental here?
Aucun commentaire:
Enregistrer un commentaire