Testing Strategy
While there are a multitude of testing strategies, we've picked one and have used it with good success.
Test the things that we can't afford to have break
We do not mandate, or even suggest, 100% test coverage, but would propose the following concepts:
- While working through features, write tests that reinforce the essence of the requested feature
- When bugs arise, create a regression test to duplicate the issue, then fix the problem
- Make sure your tests are able to be run by any developers on the team
The underlying principle of testing is to have assurances that future changes will not break the application. So it's up to each developer to determine to what extent the application needs tests.
For example: Do we need to write tests that the password reset email is being sent? Probably not. But, do we need tests to ensure a ratings application generates the correct scores? Absolutely.
Touch the database
Don't be afraid of touching the database in tests. However, you should set up your app to use a testing database instead of your local database.
Setup
Alongside your local database, which should be named something like guidelines_local, create a second database named guidelines_testing.
Then, in the phpunit.xml file, create a new env variable that points to the testing database.
<php>
<env name="APP_ENV" value="testing"/>
<env name="DB_DATABASE" value="guidelines_testing"/>
//...
</php>
Model factories
As you create/modify Laravel Eloquent models, be sure to keep the associated model factories up-to-date.
Model factories should implement states, especially for models that have statuses or boolean columns, and should use a descriptive snake-case formatted name.
Bad:
$factory->state('activeStatus', function() { // state name uses camel case
return ['status' => 'active'];
});
Good:
$factory->state('active-status', function() {
return ['status' => 'active'];
});
Database seeding
To mitigate against accidents, like emailing live customers, avoid using a production database when testing. Rather, take the time to build a robust set of data seeders to populate the application with a wide variety of randomized data.