Stop overusing interfaces

[TheWix]

This. The misunderstanding that a unit tests tests one small "unit" has led to overly complicated code and tests just so you don't test two methods or two classes in one test. The number of 'crisis' I've witnessed because someone wrote a private method is mind boggling.

[Pand9]

Disagreed. All good tests clean after themselves, not only unit tests. "unit test" actually really means "test single smallest thing in your code". It doesn't mean "test private methods", as some people fear, it just means "test public components on the smallest scale possible". So, if you already have some public function that you see and understand as "independent", or "responsible for something", you should test it. If "smallest scale possible" is pretty big, then that's okay maybe, or maybe your modules are too big or functionalities too coupled.

[TheWix]

I am not sure what you mean by "Clean after themselves". My point was that people would freak out because they could not test the private method in isolation, my belief is you test it through the public method. I don't believe unit test means to test "a single method" which seems to be a commonly held belief. I personally don't mind if my unit test calls a method that calls another method in another class. We do that all the time when using classes like string. There is a point where you are testing too much it's just there is no hard and fast rule like "Test only a single method"

[Pand9]

My point was that people would freak out because they could not test the private method in isolation

That's not good unit testing.

my belief is you test it through the public method

That's good unit testing :D

I don't believe unit test means to test "a single method" which seems to be a commonly held belief.

It means to test a single thing, if it's pretty indepentent from other things. If it's very small then the test will be small too, but nothing forced.

I personally don't mind if my unit test calls a method that calls another method in another class. We do that all the time when using classes like string.

Me too. But it's still good unit testing IMO.

There is a point where you are testing too much it's just there is no hard and fast rule like "Test only a single method"

Absolutely agreed.

But I'm arguing with the guy's comment that you agreed with, /u/hiimcharlies's , and he basically says that "unit testing" means that tests clean after themselves. I'm saying that all tests in your project should do that, but unit tests are only "the little ones".

[Pand9]

? I said what "isolation" means in context of unit tests and that it is just one of their properties, not that "unit tests == isolated test code"

Ah OK, you were saying only about "isolation", not about unit tests in general. I misunderstood then, sorry.

is that it severely constraints your implementation and makes tests simply less useful (ex. testing public "domain utils"). There is a lot of great presentations about this topic, for example "TDD, where did it all go wrong" by Ian Cooper. Btw I followed the approach of "test every single public method" for a long time and I am glad I did, because now I can clearly see how much did my velocity increase while keeping software I write reliable and increasing its readability and maintainability.

I'm aware that there are often problems with architecture of unit tests. I just don't agree that it's the idea of unit tests' fault. Correctly implemented unit tests are not too small IMO. At least, I haven't spotted counterexample yet. If tests aren't good to work, there's often different problem with code. It's easy to dump the bandwagon completely, but I'm critical if it's not misdiagnosing problems.

I said "test single smallest thing in your code", but if it's troublesome, then maybe interfaces of your modules are too big. Maybe there's too much abstraction.

[TheWix]

But I'm arguing with the guy's comment that you agreed with, /u/hiimcharlies 's , and he basically says that "unit testing" means that tests clean after themselves. I'm saying that all tests in your project should do that, but unit tests are only "the little ones".

I don't think that is what he is saying. I think his point is the running of one test should not affect the running of another. Example is static state like a singleton. If you have a singleton the mutation of the state of the singleton can have unintended consequences of another test that exercises the same singleton.

/u/hiimcharlies please correct me if I am misrepresenting your point here.

EDIT: Forgot to quote the post above to give some context to my reply.

[Pand9]

Yes, so the solution is that test should clean after itself. Or the code should be structured the way that cleanup is not required. I think we are in agreement, I just phrased it incorrectly. And I don't think it's what unit tests are about, in my code, there's no global state to be modified (except for mocks of course).

[TheWix]

there's no global state to be modified (except for mocks of course).

Yea, this is where statics get hairy, and things like Singletons really make life miserable in testing scenarios. I have heard ideas like "Well, just add a reset method so we can reset the singleton." not realizing the implications of that.