Sometimes I wonder that I am writing too many test cases which test the exact same thing. Assuming there is a class
class KlassA
def do_something
b = KlassB.new
b.do_something_more
end
def do_something_else
c = KlassC.new
c.do_some_other_thing
end
end
Now, if I have written test cases for KlassB, do_something_more and KlassC, do_some_other_thing. Should I write test cases for KlassA, do_something and KlassA, do_something_else ? Should I even write test for KlassA at all.
Why or Why not ?
Top comments (3)
It depends. Given only the context of the code you have written, it looks like
KlassAis responsible for receiving certain inputs and then delegating to methods exposed by eitherKlassBorKlassC(#do_something_moreor#do_some_other_thing, in this case). I might actually not testKlassAat all, and instead write an integration test that goes throughKlassAand makes assertions about the final state of your application (what side-effects are triggered, are DB records created/updated, etc.)Thanks for your input @reefloretto , I had a same feeling. But since I have never been heavy on writing test cases, I wanted to validate my thought over it.
There's a very good talk from Sandi Metz which explains how to decide when is enough (regarding unit tests) youtube.com/watch?v=URSWYvyc42M
As for integration/E2E/whatever tests what I do is to take into account that tests have a cost and that I want to get the biggest benefit from them with the smaller cost possible.
If I can avoid adding a test, I do. Unless of course adding the test saves me money/time/whatever other costs.
In this case, my questions would be:
KlassBandKlassCat all?KlassAor are they widely used around your app? Then test onlyKlassAunless you can find another very good reason to test B and C.KlassAonly delegating into those? Then I wouldn't testKlassAexcept for some integration.KlassAdoing some other query or does it have any other side effect? Then I would definitely test those as well.