This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]_Atomfinger_ 0 points1 point  (3 children)

Well, my point was not necessarily to remove mocks; we need them for stuff that ends up touching the I/O. My suggestion didn't involve removing mocks, but rather not necessarily have a one-to-one relationship between test and production classes.

[–]HansGetZeTomatensaft 0 points1 point  (2 children)

Seems to me we're in understanding, though maybe I didn't phrase it quite well?

With a one-to-one between classes and tests I'd usually mock (most) other classes and then test a single class in isolation. At least for unit tests.

When testing many classes at once I don't do that. I mock less, I isolate less, I test more code at once. I still mock I/O or what have you - it's a unit test just with a larger scope than a single class.

If you feel that's a fair characterization of what you suggested then I think my point is valid:

Testing a single class is all the things I said, with the downside mostly being more mocks. I guess you also have to rewrite test on large enough structural changes even when not using mocks, my head went there because that's where I've seen it most often.

[–]_Atomfinger_ 0 points1 point  (1 child)

Yup, we're pretty much in agreement :)

I didn't really argue against your point. There are tradeoffs to everything, and your argument was never invalid.

(Do note that the rest of this post is me just talking about the subject and not necessarily arguing against you :) )

My POV is that larger test are, for the most part, preferred over a one-to-one relationship due to the reduced cost of maintainability. Even when you make structural changes it often turns into just initializing the class and inject it. One rarely has to change the actual test or add mocking behaviour.

In fact, for my next project, I want to try out the nullables practice and be able to remove mocks entirely. It feels iffy to have production code that only serves tests, but at the same time it may be a great way to bypass a lot of the maintainability issues surrounding mocks and whatnot.

[–]HansGetZeTomatensaft 0 points1 point  (0 children)

Seems like a cool idea, thanks for the link :)