CODEWITHSUNDEEP
unit-testingtesting
Hans
Hans

Reputation: 2832

Testing combination of methods when every component method is already tested

Consider the example below:

void Whole()
{
   A().B().C();
}

I've already written test methods for A, B, C. These are used in many different possible ways, for example A().C().B() or B().A().C() or B().C().A(). One of them is used in Whole method. There are 3! combination when all of them corporate in.

Question: is there any necessity to write test for any used combination such as what Whole uses?

Update: Basically, A and B and C are query objects and chaining them simply and-ens them. But other idea on what these method could be are very welcomed.

Update 2: Consider h(x) = f(x) + g(x). If I test f(x), g(x), and test + operator for working fine, do I still need to test h(x) assuming the same test context exists for all of the f, g, and h function ?

Upvotes: 1

Views: 48

Answers (1)

Sam Holder
Sam Holder

Reputation: 32936

Yes. What would happen if someone came along a changed the implementation of Whole to this:

void Whole()
{
   A().C().B();
}

if you didn't have a test you wouldn't know, and the presumably bad stuff would happen in your application.

So you need to test Whole for sure. But what type of test do you need? If whole is part of the same class as A() B() and C() and these methods modify the state of that class in some observable way then you could just have a state based test which validates that the expected state changes happen when Whole is called. As Whole is void and you don't elaborate on other potential methods I can't determine if this type of test is appropriate.

If A() B() and C() call other classes to do their work or are function in other classes then you would need an interaction based test and you would use mocks or test doubles to check that the expected interactions happen when you call Whole ie verify that A() is called first, then B() and finally C().

See the difference between state and interaction based tests here

I don't doubt that your functions will perform correctly together, but you need to test that they are being called correctly. this might be better as an interaction test rather than a state test (which the testing of the individual queries would be - even though the state is in the DB). You might benefit from making the test for Whole just verify that A() is called first, then B() and finally C() and either ignore the results from the DB or provide mock implementations of A() B() and C() for those tests.

Alternatively ditch the Whole method completely and let you client call A().B().C() themselves, then you shift the responsibility for checking they are doing the right thing to them. But IMHO if you provide the Whole method you should test that it does what you expect, even if that means 15 tests (its not really that many)

Upvotes: 1

Related Questions