Why do we like testing so much?

I write a lot about testing in the Mastering Laravel newsletter. Ever wonder why it's a topic I care so much about?

In today's episode, we discuss that question and come up with a few different reasons.

• (00:00) - Why do we like testing so much?
• (01:20) - Looking back at how we learned
• (02:30) - Making it easier to join a project
• (05:45) - Tests make you more productive
• (07:45) - Shifting your thinking
• (10:10) - Silly bit

Let us help you add tests to your project.

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

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.

I had an interesting interaction with our mailing list, the daily Laravel tip newsletter. And you get nice feedback, you get the occasional person that tells you you're wrong. We've had a whole podcast episode on that. But somebody asked me a question and it really made me pause and I thought it could be an interesting topic for us to discuss today. Which is, "Hey, you write a lot of tips about testing. Why do you care about testing so much?" And it's true, I do write about testing. I would say in an average month, maybe a third of my tips, well, that might be a little high. But for sure once a week I'm writing a tip that's about testing and I do like the topic. So I'm like, "Why do I like it so much?" And, Aaron, I want to ask you, why do we like testing so much?

Well, I don't know why you like it so much. I'm just about writing code, getting it out the door. Ship, ship, ship.

Ship it.

I mean, I have one idea. It's probably not the same as what you're thinking but-

Good.

... I think that there's something interesting about the fact that the way that we came up with programming testing was around but it wasn't easy. For example, the first thing I read to learn about testing for PHP was actually a book on testing Java. I had to kind of translate that into something for testing so it was really difficult. So seeing how easy it is to test now makes me excited because it used to be really hard and I know that's an important part of our process. I think about all the times when I had to really work hard to test stuff and now I have reasonably easy ways to spin things up to test it. That's exciting to me, but that's just unique to me I think, or my generation.

Yeah. Well, PHP is not the first language you ever programmed in, is it?

No.

Okay. Because when you were talking about first language, I'm thinking literally BASIC on the Atari computer. I'm like, I don't even think there was... Testing was you ran the program, right?

Yeah.

But no, that's not the reason I was thinking. And I actually had to think kind of hard about why do I like this. Because it's undeniable, it's a topic I'm interested in. I would also say it's a topic I feel other people should know. I feel a motivation to teach it because it's beneficial, but then it's like but why is it beneficial? One reason I came up with, and this isn't the complete reason, but one thing is, well, just the way our work is, we tend to join a bunch of different projects throughout a year and we also tend to work in a bunch of different projects even within the span of a month, right? So, you contrast that maybe with somebody who's inside a company, inside a team, and they're working on one thing day in, day out. That's just a little bit of context. Now, layer testing on top of that. When I'm jumping between projects or I'm coming into something new, if they have tests I immediately feel less nervous about breaking something when I make a change. Like, "Hey, Joel, fix this bug, add this feature, blah, blah, blah." I don't have a lot of context yet when I'm new to a project to do satisfactory regression testing through the UI or whatever. So seeing a robust test suite immediately makes me more confident. And to be honest, because we don't charge by the hour, it makes me more profitable. Because I don't have to spend a ton of extra time worrying about breaking something. Having the test makes me move faster, which makes a little more money in the bank account. It's a selfish reason but does any of that resonate with you, Aaron?

No. No, I'm just kidding. I'm just kidding. I think to some extent I agree with a good portion of those. I think that I agree mostly with that but I would also... one small caveat is, if you're on a team with a project you stay with throughout whole year, there's a good chance that you may not know other parts of the product or project.

Sure. Okay.

So, I don't think that experience that you're talking about, coming into new things, is unique to us. I think we probably do it more often, but a lot of times when you start a new gig if you are there you think about the average gig, maybe it's three to five years. That means, every couple of years they're learning a brand new sort of thing and when you get there, it's not figure out the whole app. It's usually, "Here's your first ticket," you do it and you hope that you fixed it. And those tests will really help you know if you did or not.

That's true. So, it's not unique to us. We just maybe are an extreme version of that because of how frequently it happens. There's another reason though because if I'm honest with myself, the interest with testing does predate our current model of working with clients in a subscription basis. So, that's not the whole answer. I think that's maybe why it's accelerated. Feeling the pain of a project that has no test or, not to go on a tangent, but has broken tests. That's the worst of all.

I think this is your weakest reason. What's the next one?

Oh, it's my weakest reason. Boy, I better come up with something good. All right. Well, no, the other reason that I came up with was that I actually find it more productive. And not productive because I don't have to worry about breaking things. But in terms of building a feature, there are exceptions to this. But I'm thinking of one project in particular that's an API And I was just working on the API, the front end didn't even exist yet so it was going to come later. And testing that manually, with Postman or whatever your tool is, is a little tedious and especially when it comes to refactoring. Because, I think all programmers can relate to this, you start building a feature, it's going, it's going, it's going, then you hit a piece of the requirement and you're like, "Oh, actually this other way would be better."

Yeah, change the field name or anything like that, right?

Yeah. Or, this relationship should be different. So maybe it's quicker going along along, along without tests, but now if you change some stuff, if you care about not breaking what you just built, you'd have to go back and retest all that stuff again. Just kind of leaving these breadcrumb trails of feature tests. And they don't take a lot of time to write either and I think that's maybe part of my enthusiasm too is experience with the topic. Because I've crossed that initial learning curve where it does slow you down, it is more work. And you have to figure out, "Well, how do I test this? How do I test that? Why does this test flake out sometimes?" But once you get past that hump you can move pretty quick writing tests. And frankly, a lot of tests are fairly repetitive. Like the tests you use to test one CRUD controller are going to look very similar to the ones to test another CRUD controller with some differences maybe around business, logic, validation. I think that's another reason for me. I don't know if it's a stronger reason in your eyes than my last one but I do feel it makes me more productive in the whole. Maybe not in the moment, but in the whole on a project.

I would agree. I think that there's two different ways that we think as developers and that question about why are we excited about testing may show that there's a little lack of understanding maybe that there's two different ways you think. And the two different ways you think is the overall sort of understanding the project or product and then you have the day-to-day work or the daily or the small little nugget of stuff. And if you're not as experienced pumping out code you might think that those are the same sort of person. That's the same person, you're the same person, but those are two different ways that you have to structure your brain. And that's another reason why too, when we have these meetings people say, "Oh, it's horrible because it stops us from working." Really those meetings are usually a different type of thinking. And the reason why it's also stressful is because you're changing your perspective. And the reason I bring that up is because tests help you componentize your code a lot better into smaller chunks too. If you have to think about each little block of code and how you might test that to make sure it's accurate. Not the whole entire project but just your small little area. It's you write those tests and then you start to write better and smaller composable code and just better quality. And that's the sort of area that I lean on as tests have immeasurably improved the quality of my code.

That is probably one of the more classic reasons. And I thought about that. Because you're right, you're less likely to write that 1500-line controller action if you're writing tests for it. Because that would be a bear to write reasonable test coverage for. So, it does force you to think about boundaries between services and things like that, even if you're not doing TDD. I know TDD proponents will.

Test-driven development.

Test-driven development will shape the design of your code better. We don't strictly practice that but I agree with you 100%, I think that's... Is that the strongest reason for you, Aaron? Is your reason the right one?

Well, it's cliché because it's the answer everyone gives but it's true-

It is true.

... because it does happen. My answer is always best and right. I don't know why you even question that. There's a phrase that people use. I mean, there's many but there's a phrase that just drives me bananas, just grinds my gears. And that is, "Follow my lead."

Okay. There's a million things I thought you were going to say and that was not one of them.

Yeah. I hate when people are like, "Oh," especially on TV shows or something, there's some sort of clever thing happening and then one person looks at the other person and they're like, "Follow my lead." And then it's always a joke, "What are you going to do?" But why don't you just say what you're going to do? Like, "Hey, real quick. I'm going to pretend to be a waiter, do the same thing." Or, "We're going to," I don't know, "steal this painting. Act not inconspicuous." Not, "Follow my lead." By the way, that means figure it out and also do the same thing, which is not your normal thing of doing. So do two things to my just one thing which is probably difficult already, which is probably, I don't know, stealing a jewel.

Those are some interesting scenarios stealing and being a waiter. Is this a crime show we're watching or is this a comedy? What's happening? I was thinking like CSI or something, they're about to storm a room.

I've been watching too many episodes of Alias.

Okay, that paints a picture. You have set yourself up though now for people to come up to you and be like, "Aaron, follow my lead."

Oh, now you know why I don't go anywhere. Are you ready to be an adult and test your project?

Well, that's something we can help with. We have a lot of experience working with teams to get started testing. But just head over to masteringlaravel.io and sign up for the newsletter to start getting those testing tips.