Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron.

Hey, Aaron, I saw a really cool package on Laravel News, and I want to install it in our app. Do you have any objections?

Yeah, what's it for? What kind of quality of code is it? You know, why are you installing packages? Why are you asking me this?

Oh, I see we get cranky Aaron today, I love it. This is good, this is good. No, I'm teasing a little bit of a setup. Because, you know, things do show up, and sometimes they show up, and we weren't looking for it. But it's like, "Oh, that could actually be useful. I didn't know that thing existed."

Or, sometimes you go search for a package. Like, "Oh, I need to integrate with this thing," or, "I need to do something that's non-trivial." Like, maybe somebody has done some of the work for me. But there's that moment where maybe you find one or multiple packages, and you're trying to get just a quick sense, is this thing any good?

Like, do I want to bring this into my project? And I'll admit, what I look at a lot of times is the README. But today we're going to talk about somewhere else we look and I know this is more up your alley because we've talked about this before. And that is the test folder. Is that correct? Am I-

Yeah.

... yeah.

I would say the number one reason why I wouldn't want to use someone's package is like, example test in a PHPUnit folder or something like that. That's only lower than someone with no tests. So, if you have no tests that's horrible, but that's fine, versus if you have a folder called test and it just has example tests in there, that's even worse.

Oh boy. But that's actually worse to you, is that they left the default example test in there and didn't even have the cleanliness to get rid of the test folder and own their decision to not have tests.

As silly as it sounds, it's also a cognitive load on my brain that if there's a test folder, I assume there's tests in it.

So, maybe there's even a little bit of excitement. Like, "Oh, let's see what tests they have," and then you're disappointed and you're like, "Argh."

Yeah.

Okay.

I would say that would be like when you're first discovering it. But just in general, if I have a folder called Support For PHP 8.5 and inside of there, there's nothing, then I'm really upset with the... You know, what are you doing?

Delete things that don't matter, you know? So, I guess that's kind of where I look at that and say, "If there's a folder, you know, for tests, let's take a look at it. If there's no folder for tests, first of all, I'm probably not going to use the package if I can help it anyway."

Okay. So, it is kind of a hard line then. You're like, this is literally a make-or-break decision, doesn't matter. Because here's some other things people look at. How many GitHub stars does it have?

How many packages installs? You're saying it could have good signals in other areas, but if this test folder is lacking, or even worse, has just the one test in it, it's just a deal breaker for you?

Yeah, it's a collaborative thing. So let's just say it's a perfect package. It has 100M downloads, everyone says it's perfect, and it has no tests.

Then maybe all of those things have sort of pushed it above the level where I can say, "Well, I don't know why we're using this package. But it's such a small bit of code that I can see it, I understand that there's no tests.

Everyone is using it, it works fine, I'll do that." But in general, the reason you're getting a package is because it has more code in it than you're familiar with. So for me, looking at the test does two things. One, it shows that the person who made the code was thinking about all the different scenarios that I might use this code, not just for their one scenario.

You know, usually that means that they're checking the edge cases and going through them. And then the second thing is, it's a form of documentation. Because I don't know about you, but you said you checked that README. How often is the README actually really up to date with what's actually going on?

Yeah. And maybe it's not even being up to date, but it can't address every possible use case for a package in a README. It'd be pretty long, right? But the tests are more thorough.

So, maybe there is one particular use case you care about, and it's not covered in detail in the docs. And you could look at the tests and hopefully see like, does it do the thing I need? Or, does it do it in the way that I want it to do it?

Correct.

Okay. All right, so it's mostly a hard line, but I hear it a little bit of... And I'm with you. Like, if something's got 100M downloads and it doesn't have tests, I don't know if I've ever seen that, first of all. But second of all, maybe it's just a single class, or it's bringing something into Laravel that you could just copy, right?

Right.

And not even have to install the package. That's a good point.

Yeah, I think... So that's kind of why I would say they pile up so you can check the README, you can check the GitHub, the Stars. Another thing is looking at their issues.

You know, if it's a package that's up to date or something, have the issues been opened and addressed? You know, if it's something I need to dwell on a lot, I might actually look at some of the closed issues to see how they were resolved.

Okay.

Because there could be a situation where it's like, hey, this is a perfect project, but the maintainer isn't wanting to expand it. That's their own prerogative, you know?

Sure.

But I need a couple expansions. Well, it doesn't look like they're willing to do that. Do I want to fork it? Do I want to find a different solution? You know, you can kind of pick those things up from looking at the issues and wiki, and conversations and stuff too, around the packaged ecosystem.

Yeah, that's important context as well. Just, you know, it kind of all weighs in on the general health of the package. You know, I even think too when it comes to Laravel version updates, I will sometimes look at the history-

... and see like, "Hey, were they in front of it? Or, did they have it the week Laravel came out? Or, is it like three months later and people are like, 'Hey, can you bump this?'" You know, again, not that we're like installing new Laravel versions day one. But it's sort of a litmus test to me just how on top of it is the package maintainer.

Yeah. So, I would say full circle here, there's a lot of things that kind of build up whether I'm going to use this package or not. But the number one for me is actually is there tests in there? And I know, you know, we talk a lot about testing, maybe that sounds self-serving.

But it is really to me, it is the equivalent of your code. Your source code and your tests are the same thing in this project to me.

Yeah. And a package is kind of unique because there's a level of trust that you're extending by installing that package. Like, with Laravel, we see its tests, and when we're writing application tests, we kind of have this boundary in mind.

Like, well, I don't need to test that the queue works the way Laravel does internally. Laravel has got that test, and it's the same thing with the package. You know, you don't want to have to feel the need to dig in and internally test the workings of the package.

Just one other question, maybe a final question. Do you ever actually run the tests, or is it just like, "I want to see that they're there and I want to look at them?" Or, do you exercise them yourself? Like, maybe even before updating to a new version of that package or anything like that?

Nope.

Okay. That's fine, I don't either. You know, it's not a judgment thing, I was just kind of curious.

No, you know it sounds like a perfect thing to do. You know, you're going to get a brand new package, maybe check it out, run a test, but I don't do it. I just look at them and... But that's a good idea. That's why they delay there, maybe I should.

Yeah. And to be fair, maybe this would be guarded against. Like, does it run on my machine or in my specific circumstance? But they probably have like CI, and you can see, "Oh, yeah, it passed. The tests pass on 8.3 and 8.4."

You know, there's a little bit of trust there. Like, are they actually running these tests? But, you know, just seeing them, that's sort of the first pass. But yeah, I don't run them myself either. I mean, I would only run them if I'm contributing to the package to make sure my PR isn't going to break their pipeline or whatever.

Yeah. So, I don't know if you can tell it. I've been trying to keep it out of my voice, but I'm kind of sick today. You know, got a cold or something.

You got that radio voice today, man. You got to do more of this.

Oh. I just don't like this because I'm sick and I just don't want to do anything. And I told one of my friends, and she says, "Oh, so you got man flu."

As opposed to?

I don't know. And I don't agree with that. And when she describes it, it's actually very accurate, and it makes me very angry with myself, and I can't seem to change anything about it. Which is this concept of, when guys get a sickness, it's always far worse for them and like...

Oh, yeah.

... You know, woman might have a cold, and they're fine. But guys a cold and he's like, "I got to stay in bed." I want to do that so bad right now, is go back in bed.

Well, now that the podcast is over, Aaron, go back to bed.

You know, when you work with us, we don't just look at the test, we actually run them too.

Yes, that part is definitely clear. If you'd like to work with us, head over to masteringlaravel.io, and we have an option to get in contact with us and see if we have availability.