How to test multiple PHP TypeErrors in one test?

user_3351349 0
Viewed 102

I have following method:

MyClass {
   public function __construct(array $data, ?SomeObject $object): void
}

I have following test:

public function testWrongDataTypeThrowsErrorException(): void
{
    $this->expectException(TypeError::class);

    //works as expected
    new MyClass(null, new SomeObject);
    
    //this is never called
    new MyClass('string', new SomeObject);
}

And what happens is it only runs 1 test/assertion with the null parameter. The second time when I try to create MyClass with string, it never gets there. Why is that?

The same logic works if the code throws regular Exception.

I can write 2 separate methods instead, but thats very inconvenient.

Or is it stupid to test for this? My idea is that I want to test that the method accept array and only array. So if somebody would remove it from the method the test would fail.

testing phpunit unit-testing php
1 Answers

Place the expectExeception... or exepectError... only directly before the action you want to assert it for.

If you need multiple, write multiple tests methods - for each exception and error individually.

The suggestion above is how it works with Phpunit out of the box and normally keeps your tests clean.

There is however also the option to just make use of PHP here and handle it like the following:

try {
    new MyClass(null, new SomeObject);
    $this->fail('an expected exception was not thrown');
} catch (TypeError $e) {
    $this->addToAssertionCount(1);
}

Then the test-method is not interrupted and you can continue (you have to remove the earlier TypeError expectation as Phpunit will not detect it any longer).

If you feel this is more convenient than separated tests, go for it.

You can even add a helper function and pass a closure in so you can wrap it. Normally it's better to stick with clean tests IMHO, if you really must test for that.

From what you write in your question, I'd say the problem is solved in PHP since the array type-hint back in PHP 5.??? and I would not need to test for that (or you would also need to write tests for your tests, because also the tests can be changed).

If someone changes the method signature, they should have a valid reason for that. If they make a mistake, they perhaps didn't cover their refactoring with tests so the problem lies not in the code of the unit and is not to test for with unit tests.

Keep in mind, that a test should only have one reason to fail. So it's good to aim for that when writing a (unit) test.

user_3674560
Related