Automatically calling setup/teardown on traits can lead to double-initialization/breakages
Closed this issue · 1 comments
- Testbench Version: 8.1.0
- Laravel Version: all
- PHP Version: all
- Database Driver & Version: n/a
Description:
In https://github.com/rebing/graphql-laravel the tests started to fail with the 8.1.0 release due to orchestral/testbench-core@b824c5e
The project uses the convention to have a trait SqlAssertionTrait [1] with a method setupSqlAssertionTrait [2] which was initialized manually via a setupTraits [3] methods
[1] https://github.com/rebing/graphql-laravel/blob/1345744decc28c5a3833a2010531e1ee5722a3b7/tests/Support/Traits/SqlAssertionTrait.php#L18
[2] https://github.com/rebing/graphql-laravel/blob/1345744decc28c5a3833a2010531e1ee5722a3b7/tests/Support/Traits/SqlAssertionTrait.php#L27
[3] https://github.com/rebing/graphql-laravel/blob/8b156d5b98dee7e3fb86c62f42253a1d647de288/tests/TestCaseDatabase.php#L22-L31
See also rebing/graphql-laravel#1017 (comment) for a more in-depth analysis.
Since I've a 8.x branch in that project which still supports Laravel 6 (already on its way out), I still have to support orchestra/testbench:^4.
The fix on my side is easy, to stay backwards compatible I renamed the method in my project.
In my case, the breaking change was that the trait was initialized twice and thus malfunctioned (it registered a listener, which then was registered twice, breaking assertions in a couple of tests).
I don't need a fix for my project, renaming is an okay fix, just wanted to bring it to your attention. Feel free to close this issue!
The method was introduced in Laravel Framework and we add it for compatibility. I'll add a note in the changelog later today.