Unit Testing - Is it bad form to have unit test calling other unit tests

Question

I have a unit test called TestMakeAValidCall(). It tests my phone app making a valid call.

I am about to write another test called TestShowCallMe

Answer 1

I think its a bad idea. You want your unit test to test one thing and one thing only. Instead of creating a call through your other test, mock out a call and pass it in as an argument.

Answer 2

Refactor the setup to another method and call that method from both tests. Tests should not call other tests.

Answer 3

A unit vs. module....we also think tests should depend on reusable methods as well and should test at an api level testing integration of classes. Many just tests a single class but many bugs are at that integration between the class level. We also use verifydesign to guarantee the api does not depend on implementation. This allows you to refactor the whole component/module without touching a test(and we went through that once actually and it worked great). Of course, any architectural changes force you to refactor the tests but at least design changes in the module don't cause test refactor work(unless you change the behavior of the api of course implicitly like firing more events than you used to but that "would" be an api change anyways).

Answer 4

A unit test should test one unit/function of your code by definition. Having it call other unit tests makes it test more than one unit. I break it up in to individual tests.

Answer 5

IMHO, you should do one of the following:

• Create a method that returns a valid call, and use it separately for both tests (not one calling the other)
• Mock the valid call for the ShowCallMessageTest

Answer 6

Yes - unit tests should be separate and should aim to test only one thing (or at least a small number of closely-related things). As an aside, the calls to data.Expect and phone.Expect in your test method are creating expectations rather than stub calls, which can make your tests brittle if you refactor...