Next up, we have data providers. So have a look once again at these tests. And notice, in every case, we call a parse method, we give it input, and then we assert that the result is equal to this expected variable, in every single case. So in these situations, we can reach for data providers to simplify all of this. For example, if we scroll right back up, let's add a new one here, and we'll say testItParsesTags. We're going to make it a little more generic. But imagine if we had some set of input, and we had some expected value. Well, if that were the case, we could then just do something like this.

But imagine if we had some set of input, and we had some expected value. Well, if that were the case, we could then just do something like this. Parse the given input, and then we don't need to double up on expected, so we would end up with something like this. Assuming the method could be passed the input and the output effectively. Well, we can do this, again, through data providers. It requires two steps. First, you add this data provider flag to your docblock, and we're going to give it a name. Why don't we call it tagsProvider.

name. Why don't we call it TagsProvider. Next, we create that method. TagsProvider. And what we're going to do here is return an array of arrays. Each item in this array should contain our desired input and the expected output. So to start, our input would be personal, and the output, the expected, would be an array that says personal. So it would look like this. personal is the first key, and the expected result is an array that says personal.

So it would look like this. Personal is the first key, and the expected result is an array that says personal. And that's it. So have a look here. We give it a run. We'll run it, and I will filter this down. Now real quick, I'm just going to do it that time, but in the future, I have a extension that will do it for me. And that saves a little time. You can see they're just using the full paths here, but it's basically the exact same thing.

And that saves a little time. You can see they're just using the full paths here, but it's basically the exact same thing. And it passes. And notice there was one test and exactly one assertion. So this means this entire method is now superfluous. Let's do another one. If the input is this string, so let's do it again. We give it that. Then we expect that array in response. All right, let's give it another run.

Then we expect that array in response. All right, let's give it another run. And if we did everything correctly, there should now be two assertions. And there are. And just to be clear, if I were to force this to fail, give it a run, everything's working. Notice we expected X personal, but we got that. So this is a good option when you want to assert that all these different values pass to an underlying method are valid and return what you expect. So again, notice how this one is now superfluous. Let's just finish all of these up together in one go.

So again, notice how this one is now superfluous. Let's just finish all of these up together in one go. So if we do it again, then we should have, once again, that same output. Let's get rid of that one. Next, spaces are optional. So let's run it again. Actually, let's do it up here. And that should, once again, return the array. All right, how are we doing? And then we have one more, yeah, for the pipes.

And whoops, yep, sorry about that. I think that'll do it. Give it a run again. And it passes. Great. So is that everything? I think so, which means I can get rid of all of this, and this is what we get. But next, notice how the setUp method isn't overly necessary anymore because I only have one test. So with that in mind, let's just get rid of this entirely.

When you realize, oh, I'm just doing the exact same logic for every single test. The only difference is the input and the expected. If that's the case, a data provider can drastically simplify your code.