What is an integration test?

If you didn't read them yet, start with our approach to feature tests and unit tests.

Today, we're going to talk about integration tests. These are the tests that don't fit into the feature or unit test categories. This doesn't come out of the box with Laravel, but it's a level of testing we've found to be very useful.

An integration test is a something a layer down from a controller or command, which we'd cover in a feature test. While you could test it via an HTTP request or Artisan command, generally it would require a lot of setup to fully test the logic.

For example, maybe you have a controller action which fires off an event which has two listeners attached. Each of those listeners might have two or three paths through them.

To test all of that strictly via feature tests would require writing a lot of tests. I love testing, but I don't make it any harder than it needs to be.

Instead, we'd have our feature test assert only that the expected event was dispatched, but we wouldn't test anything about the logic inside the listeners.

Each listener would have its own integration test. Inside the listener test, we can easily test all the paths directly without having to set up a whole world in which to make a request.

Not only does this make the tests a little faster, but it makes them much more readable. You can really focus on the logic of the listener without having to worry about the HTTP request that triggered it.

Integration tests are great for anything that is in its own class and has a fair amount of logic:

• Listeners
• Jobs
• Middleware
• Policies
• API Resources
• Observers

The list could go on and on, but these are the most common things we test at this level.

As with our other top level test directories, we mirror the structure of the app folder for the class we're testing.

If you've never tried it, give this organization method a shot. It's made our tests much easier to find and understand.

Here to help,

Joel

P.S. Want some help organizing your tests?