Some of the unit tests are really integration tests as they rely on data to be created.
For example, Tests\Unit\Models\TeamTest::testItGetsTheFixtures relies on clubs and fixtures to be created. I understand this being a unit test for a model and this particular test actually testing the relationship between the Team and the Fixture models, it will be difficult to refactor. However we should have a look at all unit tests and write them as such. If it not possible, as it seems it is the case for Tests\Unit\Models\TeamTest::testItGetsTheFixtures, then the test should be moved in the Integration folder (or Feature folder, depending on #110).
We should also make sure we use Events::fake() in many of those tests so that when a model is created we don't fire the event (which we listen to to create roles and permissions).
Some of the unit tests are really integration tests as they rely on data to be created.
For example,
Tests\Unit\Models\TeamTest::testItGetsTheFixtures
relies on clubs and fixtures to be created. I understand this being a unit test for a model and this particular test actually testing the relationship between theTeam
and theFixture
models, it will be difficult to refactor. However we should have a look at all unit tests and write them as such. If it not possible, as it seems it is the case forTests\Unit\Models\TeamTest::testItGetsTheFixtures
, then the test should be moved in theIntegration
folder (orFeature
folder, depending on #110).We should also make sure we use
Events::fake()
in many of those tests so that when a model is created we don't fire the event (which we listen to to create roles and permissions).