Is it a bad practice for a unit test to "trust" the other?

Question

Assume I have the following two functions:

function storeObject(object) {
    // Connect to database
    // Prepare query
    // Execute query
}

function retrieveObjectWith(id) {
    // Connect to database
    // Prepare query
    // Execute query
    // Parse results

    return object;
}

And that I want to write tests to them:

function testStore() {
    storeObject(storedObject)

    // Connect to mocked database
    // Prepare query to retrieve stored object
    // Execute query and retrieve stored object

    [retrievedObject] should equal [storedObject]
}

function testRetrieve() {
    // Connect to mocked database
    // Prepare query to store object
    // Execute query and store object

    retrievedObject(storedObject)

    [retrievedObject] should equal [storedObject]
}

I could simplify the second test if I "trusted" the results from the first, like this:

function testRetrieve() {
    // Since I have a separate test for storeObject, I can use it here
    storeObject(testObject)
    retrievedObject = retrieveObjectWithId(testObject.id)

    [retrievedObject] should equal [testObject]
}

Question is

Are there any cons of using the storeObject(object) instead of rewriting its logic inside the test?

Is it considered a bad practice to do this?

Answer 1

What is your system under test? Quite often, testing a method in isolation is not sensible. Often, the value of a system is provided through the interplay of multiple methods. Then, when writing a test that verifies that the value is being provided by the system, calling multiple methods is perfectly fine.

Your test examples hint at three possible kinds of value the system may provide. First, there are two behaviours regarding how the database is used:

• Scenario: writes to the database use a particular format
  Given a database
  When I storeObject({ id: 123, name: "foo", ... })
  Then the database table objects contains a row (123, "foo", ...)

• Scenario: reading from the database understands a particular format
  Given a database with object (789, "bar", ...)
  When I retrieveObject(789)
  Then the object is { id: 789, name: "bar", ...}

These tests are likely to be integration tests since they verify how the system interacts with a particular database schema. Such tests have a lot of value when other systems use the same database, or when your system has to support multiple database schemas.

But for a unit test, we are probably interested in a completely different property:

• Scenario: can retrieve stored objects
  Given a database
  And some object with an id
  When I storeObject(object)
  And I retrieveObject(id)
  Then I get the same object back

How does the store/retrieve work internally? Doesn't matter, as long as the two functions are compatible. What specific object am I storing? Doesn't matter, as long as I get the same object back (→ consider test parameterization).

This third test should definitely be present because it likely describes the value your system is supposed to supply. Testing implementation details like the specific data formats used can aid debuggability of your system, but also makes your tests more brittle. If you change your system to use a different data format you might have to update the first two tests, even though the system continues to provide its main value per the third test.

Mantras like “every test should only test one thing” are useful rules of thumb, but only if you think about what “one thing” is in this context. In particular, consider what the system under test is (function? class? module? service?) and what value this system should provide. Then, write a test that verifies that the system provides this value, without focusing on how the system provides this value.

Answer 2

Well, no. A unit test is supposed to test one thing. It can be one particular way of running a method, or it can be an entire method if it's simple enough for that, but it certainly isn't for testing multiple methods. Therefore, one test assuming the validity of a different method is standard operating procedure. If there were a bug in the other method, it would show up in the other unit test. (This is why code coverage is important in testing.)