CODEWITHSUNDEEP
unit-testing
thur
thur

Reputation: 1074

Two assert in the same unit test method, how to make?

I'm starting out using unit tests. I have a situation and don't know how to proceed:

For example: I have a class that opens and reads a file. In my unit test, I want to test the open method and the read method, but to read the file I need to open the file first.

If the "open file" test fails, the "read file" test would fail too!

So, how to explicit that the read fail because the open? I test the open inside the read??

Upvotes: 0

Views: 47

Answers (3)

raina77ow
raina77ow

Reputation: 106385

The key feature of unit tests is isolation: one specific unit test should cover one specific functionality - and if it fails, it should report it.

In your example, read clearly depends on open functionality: if the latter is broken, there's no reason to test the former, as we do know the result. More, reporting read failure will only add some irrelevant noise to your test results.

What can (and should be) reported for read in this case is test skipped or something similar. That's how it's done in PHPUnit, for example:

class DependencyFailureTest extends PHPUnit_Framework_TestCase
{
    public function testOne()
    {
        $this->assertTrue(FALSE);
    }

    /**
     * @depends testOne
     */
    public function testTwo()
    {
    }
}

Here we have testTwo dependant on testOne. And that's what's shown when the test is run:

There was 1 failure:

1) testOne(DependencyFailureTest)
Failed asserting that <boolean:false> is true.
/home/sb/DependencyFailureTest.php:6

There was 1 skipped test:

1) testTwo(DependencyFailureTest)
This test depends on "DependencyFailureTest::testOne" to pass.

FAILURES!
Tests: 2, Assertions: 1, Failures: 1, Skipped: 1.

Explanation:

To quickly localize defects, we want our attention to be focused on relevant failing tests. This is why PHPUnit skips the execution of a test when a depended-upon test has failed.

Upvotes: 1

Derek
Derek

Reputation: 952

Generally speaking, you wouldn't find yourself testing your proposed scenario of unit testing the ability to read from a file, since you will usually end up using a file manipulation library of some kind and can usually safely assume that the maintainers of said library have the appropriate unit tests already in place (for example, I feel pretty confident that I can use the File class in .NET without worry).

That being said, the idea of one condition being an impediment to testing a second is certainly valid. That's why mock frameworks were created, so that you can easily set up a mock object that will always behave in a defined manner that can then be substituted for the initial dependency. This allows you to focus squarely on unit testing the second object/condition/etc. in a test scenario.

Upvotes: 0

TGH
TGH

Reputation: 39248

Opening the file is a prerequisite to reading the file, so it's fine to include that in the test. You can throw an exception in your code if the file failed to open. The error message in the test will then make it clear why the test failed.

I would also recommend that you consider creating the file in the test itself to remove any dependencies on existing files. That way you ensure that you always have a valid file to reference.

Upvotes: 0

Related Questions