If we test a function B, by testing a function C which calls that function B, i.e. writing a test program to test the function C which calls that function B, is the test method still called unit test, or something else?
When is it preferred to test indirectly on a function which calls the target function, and when is it preferred to test a function directly?
A popular definition of unit test is that of the ISTQB:
A unit test is the smallest testable part of an application like functions, classes, procedures, interfaces. Unit testing is a method by which individual units of source code are tested to determine if they are fit for use.
According to this definition:
Now there can be a difference between intent and test scope. If you write a test program for B by using C, it's still a unit test of C, because all you can do is to provide the input to C and check based on the output if B was correct. It's just that you deduce that B works because C works.
There is also a definition of integration test:
Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.
The usual definition of software components implies that it is independent and can be deployed on its own. Here, B and C seem not to be independent components, so we have no integration test.
This very much depends on what you consider a unit. If C is so simple that testing it separately does not make sense, then your test is a unit test.
Much more important is for your suite of unit tests for a particular unit to have close to 100% line coverage, and to test all practically anticipated code paths.
Yes, we still call it a unit-test if the functions calls other functions.
Unit-tests should test the public behaviour of a class and not the private implementations. As suggested by this Google's testing on the toilet article.
If you follow the rules of Clean Code then your functions should not be longer then 4 lines of code. This makes it impossible to not test another private function with your unit-tests.
Why shouldn't you unit-test most private functions separately? Because refactoring would force you keep updating all your implementation unit-tests. This will become frustrating when you have a lot of them, while the public behaviour should not change during refactoring and thus the test should not need any updating. You should be able to test privates with their public parent. Sometimes it might be worth testing complex privates, but wonder if they should be an separate class on their own?
Integration test:
Now if the function is part of another class it is different. Then we would call it component testing or integration testing. Your are integrating multiple classes and running a test against them. Function B would depend on Function C. To be able to unit-test Function B you could use dependency injection to isolate the function your are testing, now it would be a unit-test again.
