Automated testing. We all know we should be doing it but are you? For many of us it seems like a daunting addition to our routines and something we can always get to later. But somehow later never comes around. In this episode, host Jen McFarland chats with Steve Persch, Lead Developer Advocate at Pantheon. […]
Automated testing. We all know we should be doing it but are you? For many of us it seems like a daunting addition to our routines and something we can always get to later. But somehow later never comes around.
In this episode, host Jen McFarland chats with Steve Persch, Lead Developer Advocate at Pantheon. Steve shares his insights into the easy wins with automated testing, and the things we should all be prioritizing. We also get a second opinion on the very important question: would Northwestern’s mascot win in a fight with Wapuu?
Big thanks to Pantheon for being our 2019 WPCampus Doctoral Sponsor! We’re thrilled to have them supporting and attending this year’s conference. If you want to know more about Automated Testing, Pantheon’s own Andrew Taylor will be speaking about Regression Testing at the conference. You can also see Pantheon Migrations Lead, Lauren Kelly speaking on the “Composing Continuously” panel.
Mentioned in this episode:
Jen: ... and welcome to the WPCampus podcast. This is the podcast for WordPress people in higher education. My name is Jen McFarland and I am joined today ... Brian is off on vacation in Europe no less. He's really fancy pants, so he's left me here to do all the hard work, but I've been graciously joined by Steve [Persh 00:00:27] who is with Pantheon. Pantheon is one of our doctoral [00:00:30] sponsors for this year's WPCampus conference, coming up in just a few weeks. Steve, welcome.
Steve: Hello, happy to be here.
Jen: Great. Do you want to go ahead and start by telling us a little bit about you and where people can reach you?
Steve: Sure. So, Steve Perse. You can find me pretty much all over the internet as Stevector. It's a holdover from my calculus class days in high school. Steve plus Vector, that's my username on Twitter, [00:01:00] GitHub, WordPress.org, just about everywhere.
Jen: I'm just going to spell that for the people who can't see. It's @S-T-E-V-E-C-T-O-R. It's a mash, a math-up of Steve and vector. Brian's going to love that pun when he gets back. We are really excited to have you, and I'm extra excited because you're one of our first guests that we get to run the questions that we have now by you. In order to help us introduce you [00:01:30] to our audience, can you start by letting us know, Steve, where do you work?
Steve: I work at Pantheon. We're a web ops platform for Drupal and WordPress.
Jen: Thank you. I already gave that one away, but you answered it [crosstalk 00:01:40]. What's your official job title?
Steve: Official job title is lead developer advocate.
Jen: Which I think is a really cool job title. What do you actually do, though? What does that mean?
Steve: What I actually do ... I like to think of my job as the fun parts of my previous jobs that used
Automated testing. We all know we should be doing it but are you? For many of us it seems like a daunting addition to our routines and something we can always get to later. But somehow later never comes around.
In this episode, host Jen McFarland chats with Steve Persch, Lead Developer Advocate at Pantheon. Steve shares his insights into the easy wins with automated testing, and the things we should all be prioritizing. We also get a second opinion on the very important question: would Northwestern’s mascot win in a fight with Wapuu?
Big thanks to Pantheon for being our 2019 WPCampus Doctoral Sponsor! We’re thrilled to have them supporting and attending this year’s conference. If you want to know more about Automated Testing, Pantheon’s own Andrew Taylor will be speaking about Regression Testing at the conference. You can also see Pantheon Migrations Lead, Lauren Kelly speaking on the “Composing Continuously” panel.
Mentioned in this episode:
Jen: ... and welcome to the WPCampus podcast. This is the podcast for WordPress people in higher education. My name is Jen McFarland and I am joined today ... Brian is off on vacation in Europe no less. He's really fancy pants, so he's left me here to do all the hard work, but I've been graciously joined by Steve [Persh 00:00:27] who is with Pantheon. Pantheon is one of our doctoral [00:00:30] sponsors for this year's WPCampus conference, coming up in just a few weeks. Steve, welcome.
Steve: Hello, happy to be here.
Jen: Great. Do you want to go ahead and start by telling us a little bit about you and where people can reach you?
Steve: Sure. So, Steve Perse. You can find me pretty much all over the internet as Stevector. It's a holdover from my calculus class days in high school. Steve plus Vector, that's my username on Twitter, [00:01:00] GitHub, WordPress.org, just about everywhere.
Jen: I'm just going to spell that for the people who can't see. It's @S-T-E-V-E-C-T-O-R. It's a mash, a math-up of Steve and vector. Brian's going to love that pun when he gets back. We are really excited to have you, and I'm extra excited because you're one of our first guests that we get to run the questions that we have now by you. In order to help us introduce you [00:01:30] to our audience, can you start by letting us know, Steve, where do you work?
Steve: I work at Pantheon. We're a web ops platform for Drupal and WordPress.
Jen: Thank you. I already gave that one away, but you answered it [crosstalk 00:01:40]. What's your official job title?
Steve: Official job title is lead developer advocate.
Jen: Which I think is a really cool job title. What do you actually do, though? What does that mean?
Steve: What I actually do ... I like to think of my job as the fun parts of my previous jobs that used [00:02:00] to be a narrow corner of the job are now just the whole job. I come from a background of building Drupal and WordPress websites, starting as a freelancer, then working with a handful of agencies mostly out of Chicago. I now live in Minneapolis. When I was doing that job, it was basically one website at a time, "Make the new Drupal seven site for this university. Okay. Now, make the new website for this radio property. Now, make the new website for this magazine." In the in-between time [00:02:30] between those billable hours, I could maybe write a blog post. I could maybe contribute some open source code. I could maybe go and speak at a conference, and socialize there with the wider open source community. Now, that's pretty much the whole job. There's that public speaking side of it. There's a lot of conference travel, writing blog posts, pretty much doing, in short, anything we can to get developers, particularly, to try out Pantheon, and then whatever's necessary to sure they're successful once [00:03:00] they're on Pantheon.
Jen: That does sound like a pretty dreamy job, I have to say.
Steve: It is. I like it.
Jen: What did you get your degree in to get you this dreamy job?
Steve: A theater major, of course.
Jen: [crosstalk 00:03:11].
Steve: What else would you do to get into this?
Jen: [crosstalk 00:03:15].
Steve: Yes. I was a theater major at Northwestern university.
Jen: Brian is also a Northwestern grad. He's going to be so mad [crosstalk 00:03:23].
Steve: Oh, great. I had an unofficial policy with myself, during [00:03:30] my junior year, to sign up for one class per quarter that I really wasn't qualified for. Northwestern is a major journalism school, and I got myself early on the waiting list for the introductory journalism major class. By the time I was a junior, I could actually take it with mostly freshmen who had been the editor of their high school paper or going to become professional journalists, and I was a pretend journalist, working at the university radio station, doing radio news and wanting to [00:04:00] have more familiarity with journalism. Then I took a class, an advanced research seminar in cognition and neuroscience, which again, I was not qualified to take, but it sounded like fun. That was a mistake. But the one that really paid off was the class in the music tech department that had on its prerequisites list, intermediate html and CSS knowledge. It didn't specify, "You have to take this class before you take the other class." It just said intermediate html and CSS knowledge, which I had none of, [00:04:30] but I had spring break to teach myself. So, I did a lot of googling and learned enough, and kept going after that class, making websites for theater companies, in particular, and then all sorts of websites after that.
Jen: That is a very interesting and meandering story. That's an interesting route to get to ... How much theater are you still doing? Is this [crosstalk 00:04:57]?
Steve: Not much these days.
Jen: No? [crosstalk 00:04:59].
Steve: No. After college, [00:05:00] I did a lot of improv comedy and sketch comedy, living in Chicago, and then started doing more and more web development, kind of like the opposite route of a lot of people in that community who come from a non theater background, and then get deep into improv comedy. I was done doing a ton of that in high school and in college, and then found out I could make money playing with websites. It felt like playing with Legos and that was more [00:05:30] appealing to me than being a struggling actor.
Jen: Pay better than a standup?
Steve: Yes.
Jen: That's good. We are definitely going to have to talk offline later because I did a lot of high school theater. I had to let the dream die for college, but yeah. You said you went to Northwestern.
Steve: Yes.
Jen: I'm really excited to ask you this final question which is, who would win a fight, your college mascot or [Wapu 00:05:57]? Because I believe Brian already answered this, but [00:06:00] I want to know your take on this.
Steve: All right. Well, I'll waffle and give both answers, which was my first reaction when you told me this question beforehand was like, "Obviously, a wild cat. A wild cat would defeat Wapu."
Jen: Kill Wapu.
Steve: The question is the mascot, and the mascot is Willie the Wildcat. It's not an actual wild cat. It is Willie the Wildcat, which is a cartoon cat, more domesticated cat than wild cat. [00:06:30] Willie the Wildcat, I think would lose to Wapu.
Jen: That's interesting. Now, I'm going to have to do some googling and take a look at Willie the Wildcat.
Steve: He's not fierce.
Jen: Brian thought it was going to be ugly. He was thinking there was going to be a lot of scratching, which [crosstalk 00:06:44].
Steve: Sure, could be.
Jen: All right. I'm gonna put Wapu and Willie down as one and one in the battle.
Steve: All right.Jen: So, we're going to have to get another Northwestern grad on here.
Steve: All right, sounds good.
Jen: Today, you're going to talk to us. [00:07:00] I do want to mention that you did a Drupal camp keynote for Drupal camp, Belarus about higher ed web teams, which I want to go watch later, but we're going to talk about something a little tangential to that. So, why don't you just take us away a little bit there?
Steve: I wanted to talk a little bit more about automated testing. It was a topic I presented on at the online version of WPCampus back in January. I'll be doing a very similar presentation at High Ed Web in Milwaukee in October. [00:07:30] One of the reasons I like talking about that is because I think it can be something very tangible that teams can act on right away. The way I tried to frame the presentation for WPCampus was, "You can do this right now. It doesn't have to be something that's always put off for the next project when circumstances might be better for automated testing."
Jen: You made a good point beforehand, which is it always seems like, "This is something that's going to take a lot of work to [00:08:00] set up, and we need to set aside time for it." And the setting aside of time, as we all know, especially for something like that, it goes to the bottom of the list and it never gets looked at.
Steve: I think there's well-intentioned conversation around automated testing that it can be helpful. It can improve the code itself that gets written. It can give you regression protection. You can get 100% automated test coverage. That sounds good. But [00:08:30] for me, often felt like just ... Well, more than just out of reach. It felt very far out of reach. I was always waiting for the perfect client or the perfect project to come around that would let me do automated tests. In this job, I talk with a lot of web teams and I find pretty much everyone is struggling with that problem. I try to then think of ways to make it more actionable, more immediate. So, [00:09:00] there are forms of testing that kind of focus on the correctness of your code, unit tests, integration tests, system tests. Like, "Is it behaving correctly?" But that takes a lot of work to do. You have to write all those tests yourself. You have to define exactly what you mean by correct behavior. But there are other benefits to testing that you can get with a lot less effort.
Jen: What's step zero that you recommend for groups that want [00:09:30] to get started at this, and need that easy win kind of thing?
Steve: Often, I'm talking with web development teams where the wider context of the conversation is a desire to do a workflow overhaul, to build up some continuous integration processes, maybe start pushing code to GitHub. I went through this myself on web teams, the transition to, "We're going to do all of our code changes through [00:10:00] pull requests and that will be a good thing to do. All the code changes will flow through pull requests. We'll get a review on every single one. And then after the pull requests are merged, we'll have this formalized deployment pipeline." You end up drawing this very complex looking diagram, all these boxes flowing into one another. And yes, when the pull request is submitted, that is when the tests run great. So, I'll ask these teams, "Do you have automated tests to run?" At that moment when the pull request is created and they'll say no.
Steve: [00:10:30] That becomes the big stumbling block because if it feels like, "We have to draw all these boxes. We have to fill out all these boxes Oh, and we don't have anything to put in the automated test box." I think the simplest thing to put in that box is code style checking. The WordPress community, pretty much every coder community, has decided on some arbitrary coding style, line breaks, tabs versus spaces. Do you put [00:11:00] space in between the opening parentheses of a function declaration in the first parameter or do you not? So arbitrary things that like PHP doesn't care about. The server running the code doesn't care about all these things, but the people care about it a whole lot.
Jen: And it's fairly easy to check and see, "Yes, this found my mistake."
Steve: Yeah. The reason I recommended as the first one is because the team [00:11:30] implementing it doesn't have to decide. WordPress as a community already decided what's right and what's wrong for code styling. When the check runs and you get a green pass or a red fail, there's no argument. Either it did comply or it didn't. Other forms of testing can have false positives, false negatives. You might have to manually check a report and decide, "Do I care about this failure? Do I not care about this failure?" But if you decide we're going to [00:12:00] comply with WordPress coding standards, it's either yes or no.
Jen: I would follow that up with, that's the easy one. What would you say is the most important automated testing for [crosstalk 00:12:13]?
Steve: Right, yes. Coding styles aren't a particularly valuable test. That's also part of the reason I recommend doing them early just as a reminder that these aren't magic. Getting a green check mark doesn't tell you everything. [00:12:30] If you start with code style checks, that's a really good reminder. Like, "This is a guarantee of almost nothing at all. We're just saving time for the team members."
Jen: It just feels like a nice win.
Steve: Yeah, right. It gets you a solid foothold in, "All right. We have automated tests. They're not doing much. We can add more of them later." [crosstalk 00:12:49].
Jen: You can tell your boss that you got that out of way.
Steve: Yes.
Jen: Automated testing, done.
Steve: But a more valuable test to add, one that will [00:13:00] actually be more likely to prevent a bug from going out to production is something like visual regression testing. It's something that a coworker of mine, Andrew Taylor, will be presenting on it at WPCampus later in this summer. And it's-
Jen: That's an excellent plug. Thank you very much.
Steve: Oh yeah. Plug, plug, plug.
Jen: Folks, if you're coming to WPCampus, you want to come see that visual regression testing session by Andrew. Look it up.
Steve: The basic idea is that, especially in the context of higher ed, [00:13:30] sometimes an institution will have more websites than it knows about. There's a website on some subdomain [crosstalk 00:13:37].
Jen: What?
Steve: Yeah, there's-
Jen: You must be joking.
Steve: It was commissioned by a professor who's no longer-
Jen: Lost websites? What?
Steve: The professor is no longer there. The developer who built it is no longer there. No one wants to take responsibility for shutting the website down, but you know it is on a now insecure version of WordPress. The thing I would do in that situation [00:14:00] is I would try to get a non live version of the website. I would hope that there's already a dev environment. Or maybe just on my local machine, try to get a dev version, apply the WordPress core update there, and then just visually check between the live site and the non live site. Is anything different? Did I break anything? It's not as robust as like a behavioral or a system check that is checking for the correctness of the website or the [00:14:30] behavior. Really, all your checking is, "Did it change? It might be broken now, but does it-"
Jen: Is it more broken?
Steve: "Is it more broken? Did anything change when we updated WordPress core?" Because if you just blindly update WordPress core, you might get an angry email a minute later, a week later, a month later saying, "Why did you break that website that you thought no one cares about? But I care about it and now I'm mad at you for breaking my website, [00:15:00] and not noticing that you broke my website." It's that friction that automated testing should help. All of these tools should be helping people communicate with one another and build up trust between them. If the tools aren't doing that, if you're just doing something like code styling checks for no particular reason, then it's not all that valuable. But if [00:15:30] you can take a time consuming part of a job, like visually checking if anything broke and you can make a machine do it faster, more accurately, then you've got more time to do your own job, and your coworkers are trusting you more because the thing they need from you is happening faster and more reliably.
Jen: Couldn't have said it better myself. That's definitely a session I'll be checking out at WPCampus. [00:16:00] Just for a reminder for listeners, if you can't make it to the conference, we are going to be streaming these and there'll be recordings available later. So, never fear. You will have a chance to see the session and I definitely encourage you to look these up after the fact. I know there's going to be some other Pantheon folks there. Do you want to talk a little bit more? Again, you're our doctoral sponsor, so we're really excited to have you supporting us this year. I think you might also be paying for part of our Friday evening event, which thank you very much for that.
Steve: Great.
Jen: I'll [00:16:30] drink a beer in your honor. I think you have another person coming as well, at least one other.
Steve: Well, I will have Laura Kelly from our professional services team there. I think she's speaking on a panel about Composer.
Jen: Right. We have a panel of folks talking about Composer and updates, distribution for software, which I'm really excited to see that one too. There's a lot of good talks this year, so that should be good. You mentioned going to High Ed Web. It's [00:17:00] one of our partner conferences and so I know that's coming up in October. What did you say you're talking about at High Ed Web?
Steve: I'll be doing automated testing for EDU.
Jen: Oh, even better. There you go. People, if you're making it to High Ed Web, you want to keep an eye out for Steve there. Well Steve, thank you so much for your time today. We really appreciate you coming and talking to us, and also your support and sponsorship. I may very well ask you to come back and talk to me more about web teams because as I mentioned ...
Steve: Excellent.
Jen: ... I have a real soft [00:17:30] spot for discussing how to manage web teams mostly because I'm trying to figure out how to do it. But I really, really appreciate your time. Folks, thank you for tuning into WPCampus this week. Don't forget the conference is just over two weeks away. If you are interested in attending, we're kind of at the end of registration. But if you reach out to us, we might be able to finagle you a ticket. The schedule and more information's available at 2019.WPCampus.org. Again, Pantheon [00:18:00] is our doctoral sponsor. We're delighted to have them, and we look forward to seeing, Steve, your colleagues at the conference in a couple of weeks.
Steve: Great. Have Fun.
Jen: Thanks again.