1

For example, I'm developing a framework, consisting of 3 projects, which generate 3 dlls: A,B,C. Now I've got a feature that's implemented by method 1 in assembly A, which in turn calls method 2 in assembly B, which in turn calls method 3 in assembly C. And all of the 3 methods are public.

So in order to test this feature, do I need to write unit test code for all 3 methods? It may sound redundant in the first place, but all methods have their own logic, besides the invocation to the next method. And those logic also needs to be tested.

Nico
  • 497
  • 1
  • 4
  • 15
  • The question in its current form is a bit broad. Narrow the scope of the question and provide a reproducible [mcve] to better explain the problem. Also `What is the best....` questions tend to be opinion based so it would also serve to target your title as well before you question is closed. – Nkosi Jan 27 '18 at 14:33
  • The purpose of unit testing is to test a particular piece of code without worrying about how other assembly code gets executed. So yes you need to write unit test of all three methods. You better read about unit testing code which is dependent on other code or assembly. – Chetan Jan 27 '18 at 14:35

1 Answers1

2

So in order to test this feature, do I need to write unit test code for all 3 methods?

Yes, it would be ideal to have all methods covered by tests. But that does not solve your problem, because each method should be tested independently of the other ones.

For that, the answer is Dependency Injection. Applied to your case, your framework A would not depend on the B one, but rather on an abstraction of it. It is hard to give a very complete example since you didn't give any code, but that is the theory at least.

To achieve that, instead of passing the class B directly to A, you would pass an Interface that B implements, and in the test you would create a Mock/Stub Class which you have complete control over.

This is actually a big bonus from unit testing, because it makes your code much more decoupled. Some perks are presented here.

Gabriel Prá
  • 1,377
  • 10
  • 21
  • 2
    _because each method should be tested independently of the other ones._ - this is arguable. It should be rephrased to _because each feature case should be tested independently of the other cases and features_. If public method of library `B` used only in library `A` - then you don't need to test it independently because it already covered by tests of `A`. – Fabio Jan 28 '18 at 21:54
  • Thank you for your insight! I agree with the first part. About the second part, though, I argued that library `A` should not depend upon `B` directly, so testing `B` through `A` doesn't seem right, wouldn't you agree? I'm not seeing a case where a public library `B` would exist with the solely purpose of being used in `A`, where not testing `B` would make more sense to me. – Gabriel Prá Jan 29 '18 at 17:03
  • 1
    In tests you should abstract everything which makes tests slow or everything which have a global/shared state. In case library `B` represent something which have a state(database) or makes tests slow(web service), then library should be abstracted. In case `B` represent application logic you should use actual implementation. In actual application you can still use abstraction and inject implementation if you want. In tests for `A` you should tests it's logic and using `B` with app logic is implementation details. – Fabio Jan 30 '18 at 00:16
  • @Fabio, let's say my feature doesn't involve any slow operations like database or network actions. just as i said lastly in the question: 'but all methods have their own logic, besides the invocation to the next method. And those logic also needs to be tested.' In this case, i think maybe i have to write unit test code for all 3 methods, despite that all the testing code have similar test initialization setup, invocation logic and result assertions. – Nico Feb 04 '18 at 08:47