1

I discover mocking strategies after 50% of tests was writen, and I'm confused about how much focus unit tests should have, for example on class method. I know that for external dependencies you should mock those but what if we call some other method in the same class. Would this considered to be dependency? ... Because we want to test correctness only the method that we are testing... right? But where unit test focus ends?

Unit test should test in OOP the smalest block of code... and 2 tests should not be dependant. So if the smallest block of code is class method, the unit test should test 1 class method only. But if someone modify one method and test for that method fails, it will fails all other method in class that depends on it. So in order to make test truly independant i should mock dependants method?

My thinking before writing my first test was that unit test is testing smallest group of code like class method or function and make assertions obout it's side effects... What are your thoughts about this and what should be best practice.

marked as duplicate by Telastyn, user40980, durron597, Robert Harvey, user22815 Jul 7 '15 at 2:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

0

Perhaps you could rephrase your question to: What exactly is a unit in unit testing.

I think it is commonly agreed upon, that, if you are doing OOP, a class holds for a unit. But there is no formal definition of that. You could do unit-tests with whole subsystems, mainly testing the glue code, but indirectly all of the dependencies together.

There is a nice article by Martin Fowler on the "problem" of a unit.

I know that for external dependencies you should mock those but what if we call some other method in the same class

Mostly you define an object under test, say a customerservice. This customerservice is called from another object. This behaviour trigger your tests. The customerservice makes calls to the customerrepository. These calls are perfect candidates for mocking.

You are testing the customerservice and want reliable answers to it`s behaviour. From this it should be clear, that it makes no sense, somehow to mock calls on yor object under test. If you have to make a call to another function of the same service, that is part of the test.

Would this considered to be dependency?

Not in the common sense of dependencies meaning external dependencies.

But where unit test focus ends?

By the borders of the unit you test. In the example given all methods of the unit called customerservice.

  • Unit test should test in OOP the smalest block of code... and 2 tests should not be dependant. So if the smallest block of code is class method, the unit test should test 1 class method only. But if someone modify one method and test for that method fails, it will fails all other method in class that depends on it. So in order to make test truly independant i should mock dependants method? How would you comment that? – user157581 Jul 5 '15 at 17:22
  • As written above: It solely depends on your definition of unit. If you define unit as only one method, you have to code in such a way, that one method does not call another. You should not think too religious about that. – Thomas Junk Jul 5 '15 at 18:37
  • Well its not obout the definition of unit that is buging me, its obout what programming is all about, to not repeat your self... – user157581 Jul 5 '15 at 19:39
  • 1
    @urosjarc the smallest block of code in OOP is the class. Otherwise, why are you grouping code into classes if methods are so unitary? They're not, they're parts of a unit, where each unit is the class. That's why you write OOP code in the form of classes. – gbjbaanb Jul 5 '15 at 21:52
  • @gbjbaanb Fair enough, you suggest valid point on this mather. Thank you for your input. – user157581 Jul 6 '15 at 19:51