Easy Query Filters with Laravel Pipelines
This episode is for members only

Sign up to access "Easy Query Filters with Laravel Pipelines" right now.

Get started
Already a member? Sign in to continue
Playing
06. Testing individual filters

Episodes

0%
Your progress
  • Total: 35m
  • Played: 0m
  • Remaining: 35m
Join or sign in to track your progress

Transcript

00:00
When it comes to testing this functionality, you could go ahead and test your entire controller in a more browser-based HTTP test or you could go ahead and write an integration test for
00:11
each of your filters or do both. Now we're going to go ahead and focus on testing these individually. They're not quite unit tests but they're not quite feature tests. I'm going to put them in the feature tests directory but we're going to kind of call
00:24
them integration tests. The first thing is just to set up my testing environment because I have a fresh Laravel project here. I'm just going to head over to phpunit.xml.
00:36
We're going to come down and uncomment these two lines here which is going to switch over if we just get rid of these, the database environment to SQLite with memory so we're not actually writing anywhere. What we can now do is just go ahead and run phpunit just to check everything's working
00:52
and it looks like it's not just at the moment. Let's have a look here. Of course, we've got two default tests. They're failing because we're trying to hit the home route which doesn't exist so let's
01:04
head over to our test directory. Let's delete this example unit test and let's get rid of this example feature test. Let's just run this again and there we go. We get no tests executed.
01:16
We're going to create out a test in here which is going to live in the feature directory although you could move it and we're going to call this unsolved query filter test. Let's go ahead and create that out. Let's open that up and let's start writing this out.
01:37
Now we're going to be using the database here so let's make sure we pull in the refresh database trait so our migrations get run and we actually need to create out a fake discussion or a couple of fake discussions in here and we don't have a discussion factory at the moment so let's go ahead and run make factory and create a discussion factory.
02:01
Now we can go ahead and create some fake discussions. Let's go ahead and assign these two discussions here. We'll go ahead and create a couple of these so let's say times two. We are going to go ahead and create these out and let's just test this out by dying
02:17
and dumping on the discussions count just to make sure they're good. So we'll go ahead and run php unit and if we have a look at this of course we're not passing a title in so we could do that directly within create or we could fix that up inside of our discussion factory so let's do that now.
02:36
So the definition for this is pretty much always going to have a title. It's required so we will use faker to create our sentence for this with just five words. If we run our test again sure enough we get two dumped out because we have two discussions. So for this to test out a unsolved query filter we probably want one discussion which has been
02:59
solved and one discussion that has not been solved. Now to do this really easily within factories we can use the state method and we can pass in a new sequence. What this will do is allow us to pass in two arrays one with the solved at filled and one
03:14
with a solved at not filled. Let's make sure we pull in sequence first of all and in here we'll set solved at to null and in the second one we'll set solved at to the current date and time using the now helper.
03:30
So now what we'll have are two discussions one which has not been solved and one which has been solved. Great. Okay so the next thing to do is new up our filter so let's new up our unsolved query
03:43
filter and we don't need to pass anything into this because it doesn't require anything in the constructor but now what we want to do is go ahead and handle it. So let's go and assign this a new variable called filtered just so we're very clear and let's call the handle method on our filter.
04:02
So let's open up our unsolved query filter we need a builder into this we need next and we need a value. So next is going to be the tricky one. What do we pass in there?
04:12
Well let's focus on the builder first of all that's just going to be a raw query builder from our discussion. Now the next callable we're not quite sure at the moment so let's just pop null in there and for the last one we can just pass in true or a string value with one or a string value
04:30
with true it doesn't really matter this is basically what gets passed into the query string we know that comes through as our value. So let's go and just pass in true as a string and let's go and just run this test and just see what happens.
04:44
So if we run phpunit we get a value of type null is not callable now we know that because null is going to be passed in as next and we need to be able to call next passing in the builder. So how do we do this?
04:58
Well we can just kind of mock this with a function so I'm just going to use a shorthand function here which accepts in a builder and returns the builder that's pretty much all we need to do because when we call this and pass the builder through we're always going to be chaining on where null so we can just do that to kind of mock it.
05:16
Okay so now that we've done this let's just run our test of course we have no assertions at the moment but what's our assertion? Well our assertion is that the filtered count is one because we have one solved filter one solved discussion and one unsolved discussion.
05:32
So here we can just go ahead and say assert equals and we can go ahead and say one and just say filtered count because we know that that gives us a builder back and we can just use count directly on that. So let's go ahead and run phpunit again and there we go we get green.
05:53
Now in reality each of your individual filters are not going to get any more complicated than just taking in a value and just doing something with that data. So really you can just use this structure here to write your own tests for the filters that you create in your own app.

Episode summary

In this episode, we're diving into how to test individual query filters in a Laravel application. Instead of running full feature or browser-based tests, we're focusing on crafting integration-level tests for each filter, which are a nice balance between unit and feature tests.

We start off by preparing our testing environment—switching the database config to SQLite in-memory (so tests don't mess with real data) and cleaning out the example tests Laravel gives us by default. With the slate clean, we create a new feature test specifically for our UnsolvedQueryFilter.

Since we need some fake data for the tests, we set up a factory for our Discussion model and use Laravel's factory features to make two discussions: one that's marked as solved and another that's not. This gives us a realistic test scenario.

The test then uses our filter class and simulates what it would do on a real query. We run into a little issue with the next parameter (needed by the filter's handle method), but we work around it by passing a simple anonymous function. Finally, we assert that only one discussion is returned when we apply the "unsolved" filter—just as we expect.

The key takeaway here: these filter tests are straightforward once you set up your data, and you can copy this approach for different filters in your project. It's a great way to keep your logic solid, quick, and easy to maintain!

Episode discussion

No comments, yet. Be the first!