Why Bother Testing? with Jess Sachs

EPISODE 61

[EPISODE]

[00:00:25] Al: Hey, everybody. Welcome to Enjoy The Vue. I’m Alex, and today today on our panel, we have Tessa.

[00:00:16] T: Hi.

[00:00:17] T: Ari.

[00:00:18] Ar: Hello

[00:00:20] Al: Our special guest for this episode is Jessica Sachs.

[00:00:23] JS: Hey, everybody.

[00:00:24] Al: Would you like to introduce yourself? Give us some background?

[00:00:26] JS: Yeah. So, my name is Jessica. I work at Cypress.io as a tech lead for the component testing team. I found my way there after working on Vue Test Utils for Vue, which if you don't know, is the official Vue library for testing your components.

[00:00:43] Al: Cool. Well, since you're here and we have you and we should probably talk about this, I guess I'm going to just softball this to everybody. Does everybody here like writing tests? Tessa?

[00:01:01] T: I wish you had given me some advance notice for this question.

[00:01:04] Al: I'm sorry.

[00:01:05] T: I like writing tests in theory, when I have time to write them. My main struggle is that I always trip up on how to write the test, and then when I try to find the thing that I need in the docs, I can't find it.

[00:01:23] JS: Okay, cool.

[00:01:25] T: I like console logging very much, though.

[00:01:28] Al: How about you, Ari? Do you like writing tests?

[00:01:31] Ar: Not generally. Honestly, it depends somewhat on what I'm testing. Writing tests for just like straightforward algorithmic functions, I actually do enjoy that. Because the test itself is super simple to write. You're just like, “I expect this output. Yay.” But when it comes to testing on the front end, writing unit tests for the front end, I really don't like it at all. However, I would say end to end tests on the front end can have a pretty awesome satisfaction factor when you're watching the test run in the browser. Really, I’m just in it for watching the test. Actually writing them, no. Not as much.

[00:02:15] JS: I feel you. The first moment, I remember I started as QA and the first code I ever wrote as a software person was an end to end automation script. It was in Ruby or Python, and watching, and it was for iOS. So, I got to watch my app tap around, and it was just the most euphoric feeling I've had in my career. Just seeing the thing move without you touching it, it's just like, “What?”

[00:02:45] Ar: If you haven’t experienced it, and you think we're crazy, just go try it yourself. I swear, it's a thing.

[00:02:53] Al: Having come from doing unit tests and stuff in Python at previous jobs, that is the – I like to call it the most exciting, boringest thing you can do. Because if everything works, and you have everything done correctly, at the end of it, it just goes, “Okay.” That's it. That's all it does. There's not any big like confetti or fireworks. I mean, you can set it up to probably do that. But it does its thing and if everything goes correctly, nothing happens. It's when something happens that you’re like, “Oh. Error messages.”

So, I go back and forth on enjoying writing tests. When I'm having to fight with my tools to write the tests, it is less enjoyable.

[00:03:41] T: I think also like going back to what Ari said about the context or like the reason you're writing tests, when I've been in situations where I have to write tests, because we need 100% test coverage, that's the funnest, isn't it?

[00:03:58] JS: Test coverage is an arbitrary stat and I don't know, it's a construct that we don't actually need.

[00:04:05] T: How do you feel about writing tests? Are you allowed to answer that?

[00:04:09] JS: I am. I hate writing tests. I have it on good authority that so does my boss, and that's why he made Cypress, which I found is really funny. I'd never asked him that until we were in a workshop together. He was like, “Yeah, I built Cypress because I don't like testing.” I was like, “Wow, what a way to put yourself in your own little hell.”

[00:04:34] T: It’s annoyance driven development, for sure.

[00:04:37] JS: Yeah, ADD. I don't know. He's been doing it for seven years. I was like, “You really set yourself up there for a fun career.” But yeah, I don't like writing tests. I like, like many of you, I like unit tests. They're very clear. Like Tessa, I don't like setting up the test. That's the most annoying part, is getting the component to mount, because once it's mounted, once it's like in the document, you're like, “Oh, I know how to get things in the document and make sure they're there.” And then everything's like normal.

But getting the test like getting the component first mounted is the biggest hurdle. Yeah, I can't stress that enough. So, I like to view component tests in four steps. The first is that you mount the component and that's the hardest part. You're doing things like mocking your entire app environment. So, if a component depends on Vuex, suddenly you have to learn how to mock Vuex. And those kinds of challenges can lead people to rabbit hole and get frustrated with the process. I've been there.

So, you first overcome mounting the component, and once it's in the DOM, it's pretty easy to test. As JavaScript developers, we all know how to get elements from the DOM. So, you have your component mounted, and you need to check whether it contains text. Finding the text of a DOM element shouldn't be too scary for us, and then making sure the text contains what we think it should. That's a pretty easy step too. So, it's like you mount the component, you find the thing you're looking for, and you make sure it is what it is. Sometimes there's a middle step, where you click on the component and then you make sure it is what it is.

Those are the four steps I see in any component test. I echo basically all of your concerns with component testing, especially the one where you want to see it run. That for me is super fun. Ari, you mentioned it's so satisfying.

[00:06:44] T: Yeah, that's so reassuring to hear, especially that you also find mocking Vuex frustrating because I think that's something I brought up in our previous episode as a particular part of testing Vue specifically that I always struggle with, especially if you have a lot of modules. Yeah, those steps really remind me of the steps that you need to take to solve all the mysteries in Blue's Clues. And now I really want like a Vue’s Cues or something, like a testing song.

[00:07:13] JS: Oh my god. I'm not going to write that song. That’s embarrassing.

[00:07:18] Al: We just figured out Vue’s Cues. We just figured out Vue’s Cues.

[00:07:27] JS: We just figured out Vue’s Cues, and what do you say last?

[00:07:31] Al: Because we’re really smart.

[00:07:31] T: Because it’s really fun.

[00:07:34] Ar: Oh, boy. Am I too old for this conversation?

[00:07:38] JS: Yes.

[00:07:37] Al: Maybe.

[00:07:38] T: I started watching Blue's Clues maybe as a teenager.

[00:07:41] JS: I think Tessa, that’s great. But I'm glad that it's reassuring. It's just such a struggle for people. The part that gets weird is when suddenly you don't return anything, like mount doesn't really return an input/output, right? It has a side effect of attaching to the DOM. That's just kind of weird for people because they're like, “No, unit tests are inputs and outputs. What is this side effect thing?” The way I like to explain it is the contract of a component is to output onto the screen. That's it. You mount a thing, and it winds up on your web page. And then you make sure it's the right thing. So, it's very similar to a unit test, except your output is something happening on the web page.

[00:08:33] Al: Yeah, I tend to – I know that, for me, I tend to think of like, when I'm writing tests, it's always, what is the person who's going to use this, needing it to do? Right? So, it's always if you're doing end to end tests, you're approaching it as a user. As a user, I should be able to interact with the page this way. So, with my unit tests, it's always like, as a developer, if I use this component, and I give it this prop, it should spit this other stuff out. It happens to be mounted to the DOM.

[00:09:06] JS: Totally. Yeah, totally. I'm actually in the middle of writing a course for Vue Mastery, and one of the things – I know it's very exciting. It's called Real World Testing and it follows up from an intro to state management course that Adam Jahr is doing. We did a course called Unit Testing for Vue Mastery that I consulted on, and it's about the basics. It goes over what the docks teach you, in Vue Mastery style way, so it has all the great animations, and it is very visual course. It tells you like, how do you actually render your component on the screen, and how do you use the basic Vue Test Utils API. And that's a great intro point. But the thing that people really get stuck on is, “What should be in my tests? How do I test real world application with a router and store?”

The basic stuff is usually pretty easy for folks. But where I get a lot of questions is when you hook it up into a real code base, and trying to get people to think like a user. That's the tricky part.

[00:10:13] Al: Yeah, I would. I'm excited. I will definitely be looking forward to that course, because I have those questions constantly.

[00:10:24] T: All the time, especially because a lot of – yeah, these example code bases are like, “Here is an app that is designed perfectly to be tested,” and not like, the way that real world apps are, which are even more better designs to be tested. Just kidding.

[00:10:41] JS: It's really funny, because since this course is structured such that you're not building the application as you're testing it. So, it's kind of the scenario that many people find themselves in when you inherit a code base that has no tests, and was not written with testing in mind. It was kind of funny that it happened like that.

So, Adam, he wasn't writing his code with testing in mind, he was writing it to demonstrate state management and router in the simplest way possible. So, the kind of app that we're testing is one that wasn't built for testing in mind. So, because this course is the follow on for intro to state management, Adam Jahr wasn't building it for testing. He was building it to explain state management and routing as simply as possible. So, the situation you find yourself in is that of many developers, where you inherit an application where the person wasn't thinking about testability. And that's not an uncommon scenario. That's pretty normal.

[00:11:47] T: Or you procrastinated on your own tests. Inheriting would have to be –

[00:11:52] Ar: We would never.

[00:11:57] JS: All the time, it's like, “Oh, I'm just going to get this out to beta test it or behind a feature flag”, and then it's three months later, and you're like, “This thing needs to grow up, and it has no tests.” So, that happens all the time.

Yeah, so that's something I'm really excited about. In the first lesson, we go over, I have to teach users how to pull out a router link from a presentational component. So, something that's simply supposed to render data onto the screen, it's not even stateful, there's no interaction. It depends on router link, just an A tag. That becomes very difficult to test. You have to immediately learn how to mock router out in your simplest component.

[00:12:45] Al: Yeah. I have definitely run into the like, router testing issue. We have that happen at work quite a bit where we will be looking – even just like looking at route and like something somewhere is injecting router in and you're trying to mock it and it just gets angry. It doesn't want to be modified. And you're like, “But I need you because I'm trying to set up the current situation.”

[00:13:15] JS: I don't mock the Vuex router, the Vuex or router, or any plugin. I just treat it like it's real. I find that mocking both removes you from what will actually happen in production, as well as makes your test really coupled to the source code. So, if you change your source code, you have to go into your tests and that's really not ideal.

[00:13:42] T: Every time. I’ll add some Vuex, an extra or something to a component, and then I'll run my test. It'll break and I'm like, “But I didn't even do anything. Oh, yeah, no, that's right.”

[00:13:56] Ar: Yeah. Let me just mock that, again.

[00:13:56] JS: I have cute little helpers for that, like really early on, I was working with Vue [inaudible 0:14:02] and I just wanted – in Vue [inaudible 0:14:05] , there's this globally injected function that's like dollar T for translate. And it lets you translate any string. So, instead of just writing English in your template, you'll reference some JSON file that was passed into your app. But all this is like setup at the root level. So, in your unit test, you're like, “Oh, how do I do this?” Or your component tests, you're like, “Oh, how do I do this?” So, I have these little helper functions that set up any plugins. So, they set up a router or a store or ITN with all the defaults you have for production. So, there's no mocking of every single method. I don't know why this isn't done by default in the Vue CLI like starter code, but it's really simple. Again, in my lesson, like lesson three, I show how to do this. It's a lifesaver.

[00:15:00] T: So, what do you do, I'm not sure if this is included in those use cases, but what would you do if like your store basically requires a lot of things from an external API, and then those all trickle down through multiple layers of sub stores that transform that data?

[00:15:18] JS: Yeah, the question, for me, when I look at any advanced file is what happens when you import? Does anything run when you import the file? That's the first thing with making things testable, is anything that's a side effect that executes immediately when you import it needs to be a function. The first thing I do with the Vuex store, just starting from like that basic, you've said Vue add, Vuex from Vue CLI. You're getting the basic scaffold. The first thing I do is, instead of exporting the new store, I just make a function to create the store. And then the test I call create store. You can kind of pass in your own fancy object that will wind up on state. That's how I mock out the initial state for stores, and merge it with the real stuff.

[00:16:09] T: Sorry, maybe I misunderstood. I thought you were thinking that you like to treat the stores real. So, I took that to me like you were using the actual store. But it sounds like that's not what you're saying?

[00:16:16] JS: No, it is. It is. I am using the actual store, I'm just wrapping the creation of it in a function so you can do it over and over and over again in each one of your setups. Instead of having the one store that you get by default, like in your store JS file, it's usually like export default, new Vuex, and you pass in your config. In the test, you just wrap that in a function, and then you call the function so you can keep setting it up. [00:16:47] T: So, when you say using the actual store, does that mean, like you're using the store as it was written, except for cases where, let's say you're making an API call or something, so you need to stub that part out? So, you are kind of augmenting the original store code?

[00:17:03] JS: Yeah, so for stubbing, you can either, for API calls, you can either go the way of stubbing axios, in which case you're using an actual library, or you can go the way of making your Vuex store a little more testable by injecting a wrapper, essentially. You make a file that's the intermediate between fetch and the Vuex store and you mock that file. So, that's also why you'll see the services pattern. Sometimes inside of the root level, you'll see something like a services folder, and you'll have like one file per endpoint. That's a really good way to mock your Vuex stores network calls, so you don't have to go straight into fetch or straight into axios, which are implementation details. Your test doesn't care how the data gets there. They just want a promise to resolve with the JSON. API testing is very finicky. It's very difficult. So, there's a few different ways to skin it.

[00:18:09] T: So, it sounds like for the most part, your main or sometimes only choice would be to restructure your store to make it more testable?

[00:18:17] JS: Always. You always want to restructure your code to make it more testable. It would be nice if you didn't have to. But you know, the checklist of things I look for is, what is executing immediately when I import the store? Is there a way I can get a pristine new store from a function call? How do I just have a really sandboxed setup for a store? And then how do I define these boundaries between my API calls, and what the store uses? So, how do I make a clean contract that my tests can stub out? There are a few other tricks that I do for stubbing data and API calls.

[00:19:02] Al: Yeah, we're having to do a lot of like mouth coding here, where it's like, “Oh, yeah. Well, you have to do like function open curly bracket. Yeah, we don't need it. I don’t feel like that’s probably not something we need to do.”

[00:19:18] JS: Just need to follow.

[00:19:21] T: I guess what I'm wondering is like, if you're in the situation where you inherited a code base, and it was not written with the intention of testing, and then your first task is to add a new feature, and the team has, let's say, decided now that testing is required. How would you go about estimating the scope of that ticket?

[00:19:39] JS: Maybe because I'm a little rude, I would say, “How testable we think your source code is, and would you like to share with me?” I'm a little rude about that, though. They wrote it, you just showed up here. So, they're the experts, and they can help you out. But functionally, if I didn't have somebody to pester, I would figure out what the problems in the codebase were, and I would just pick one section that was kind of plaguing it. I would start with the simplest component that has no dependencies. I start with something that's a prop only display component. And then I kind of work my way up the component tree, all the way up to a Vue, or a page.

So, start with the smallest component that's maybe only styles, a template, and maybe data, and you just keep working your way up the responsibility chain. So, we can talk a little bit about, I think Ari said that E to E tests are satisfying to watch. But do you find them easier to write, Ari?

[00:20:49] Ar: I do find them easier to write. I think my biggest struggle with E to E tests is that I maybe didn't always write my code in a way that had clear selectors, which goes back to writing your code so it's testable. But yeah, oftentimes, I don't always know what the best approach to selectors is.

[00:21:17] T: Yeah.

[00:21:18] JS: That’s a fun one. What do you think Tessa?

[00:21:21] T: The last time I wrote E to E tests it was in Selenium, Python and we used – it was called X something. I don't remember the type of selector. You can get it when you right click.

[00:21:30] JS: Xpath.

[00:21:32] T: Yeah. Apparently, there were some issues with it. Or there weren't some niceties. So, our test integration engineer, test automation engineer, wrote a bunch of helper functions and little libraries to smooth out some issues there. We also had a big discussion about, “Should we have IDs that are special to testing or classes that are special to testing?” I think at some point, we talked about the data hyphen properties. I don't know how I feel about properties that are specific to testing. It feels like a good idea and at the same time, it kind of feels a little bit to me, like, the thing with functional CSS where your template feels a bit cluttered. So, because of that, the data dash feels a little bit less icky.

[00:22:23] JS: I have a really good answer to this. Actually, my first question is, when did you have to do the XPath selectors, Tessa? What time was that, year wise?

[00:22:36] T: Maybe four, almost four years ago now.

[00:22:39] JS: 2016. That's about right.

[00:22:43] T: I think, ’17. It’s 2021.

[00:22:45] JS: Oh, Jesus. Is it though? Is it really?

[00:22:49] Al: Yeah, it's March –

[00:22:51] T: I mean, it’s the second year of 2022. 2020, I mean. Oh, my goodness.

[00:22:54] Al: March 2020, day 360 something.

[00:23:00] JS: So over it. So, the funny answer to this. So back in the day, XPath was a great way for QA engineers, who had no control of application, to test it. Because oftentimes, QA engineers didn't have commit access onto the repos. So, sometimes when you were in a pinch, you couldn't modify the source code at all and you had to use complex selectors to maybe get the nth item on a UL. You're looking for some item that has the word dog in it, and you have no way to select which line item it is.

So, you end up writing these crazy XPath selectors, which are, how do I describe it? It's like this weird, hybrid query selector all, that lets you do joined attributes. So, you get like all the IDs, you also get like positionally, how far down the DOM you're going. It's this overpowering selector.

[00:24:08] T: It's a Rube Goldberg machine held together with toothpicks, basically.

[00:24:12] JS: Yeah, toothpicks and query selectors.

[00:24:17] Al: More specifically with XPath too, to make it clear, it's not just HTML that you can query with XPath. It's really meant for XML documents, where you don't have CSS selectors, necessarily. So, that's why it was invented.

[00:24:33] JS: Yes, totally. HTML, XML type markup where you have these attributes you want to use to traverse any tree, right? Any tree would do it. But we've kind of grown up out of XPath. I don't think a lot of us have to write XML on a day to day basis. Thank God. So, the fashionable thing, I think, now is to use –

[00:25:00] T: YAML. Was that not it?

[00:25:08] JS: Exactly. Oh, my God, Tessa. I like to write my spec files in YAML.

[00:25:15] Al: I thought we were all using TOML. When did we change to YAML?

[00:25:19] JS: I made TOML cool again.

[00:25:23] Al: [inaudible 00:25:23] made TOML cool again. Thank you.

[00:25:26] JS: Did it really?

[00:25:27] Al: pyproject.toml was a pep thing. Yeah. Anyway, sorry, completely off topic, anyway.

[00:25:35] JS: Well, okay, technically, it was like, the first language I got good at. My first, first language was Objective-C, which is, I kind of pride myself on having an obscure first language.

[00:25:49] T: Nice. So, your first first language was Objective-C and your first language language was Python?

[00:25:54] JS: Yes. Yeah. That was the first time I wrote code that worked well, by myself. Back to XPath, though, it's such a mess. Now that QA engineers generally have more commit access, people are able to adjust the selectors so that they're more semantic. There's a great web page in the testing library documentation. So, it's called “What query selector should I use?” and users don't look at the ID or the XPath. They are closest to accessibility. So, the number one and two selectors that can see [Dods 0:23:37] the author of testing library, the number one and number two selectors he advises people use are accessibility based, the ARIA label and the ARIA text. I think that's a really cool modern shift from XPath.

[00:26:53] Ar: I also feel like you can coordinate yourself into extremely brittle tests with the selector you choose.

[00:27:00] T: Yeah. It reminds me of a discussion that I had once with one of my early teams about like, the value of BEM and like, what it brings to the table and how like, whenever you restructure your elements, then you have to like restructure all your BEM.

[00:27:19] JS: Do you prefer utility classes?

[00:27:21] T: I do not. But I also don't use BEM.

[00:27:25] Al: Yeah, I kind of hurl a bunch of CSS at the page and then terrible things come out. So, I'm not allowed to do design.

[00:27:32] Ar: I just go with what feels right to me.

[00:27:38] T: Always a good strategy.

[00:27:40] Ar: I mean, I say it like I'm doing it sarcastically, but not far from the truth.

[00:27:48] JS: I feel like people have two answers to a lot of questions. This is super true for testing, too. There's the interview answer that you give when somebody asks you, before you have the job. And then there's like what you actually do. What's your interview answer, Ari?

[00:28:03] Ari: I just pray they never ask about CSS and so far, they haven’t.

[00:28:08] JS: Good. Good.

[00:28:10] Ar: The trick is to interview at places that don't have a full-time front-end engineer already. Because then no one asks.

[00:28:18] JS: Right. They don't know what to ask. I got asked a very hard question. I interviewed at one place before I interviewed at Cypress last February. And their UX developer asked me a very specific question on how to access like – it was nuts, he was like, “How do you change the color of an element that's like way sibling and out of the way of some button using no JavaScript and only CSS?” I was like, “What? I have no idea.” It was a trick answer, and I kind of hate these questions.

[00:29:00] Al: Yeah, it's like, you gotta use like a plus selector, and then nth child or something, really.

[00:29:05] T: Really the answer is, “Why would you do that?”

[00:29:08] JS: Exactly. You're right. I was so into it. I was like, “How do you do it?” It was a really fun question. But the answer ended up being like, you separate the input from the label and then you can tag it wherever you want, and that would update some pseudo selector that you can get access to. I was like, “That's really messed up.”

[00:29:31] T: See, given your earlier comment, I thought maybe your answer would be, “I don't know, you wrote this markup. You tell me why you came up with this situation and how we're going to get out of it.”

[00:29:42] JS: That’s a good one.

[00:29:43] Al: Yeah, that is definitely the one where, if somebody comes to you during an interview, and they say, “Hey, how do you do this weird archaic thing in a language that nobody does?” You go, “I wouldn't. And if I saw that in a pull request, I'd say you need to change this.”

[00:30:00] T: It's like putting “important” on your interview response.

[00:30:06] Ar: I just like doing like five pseudo selectors chained together, just for funsies. Again, I say that like I'm sarcastic but I definitely did write a selector recently that I think with at least four pseudo selectors.

[00:30:21] JS: That’s the beauty of SaaS, right? It's so tiny to just write five pseudo selectors. You can do it on one line, and generate some beautiful markup.

[00:30:31] T: That's what I really liked about SaaS, because my approach is generally like, treating it like nesting boxes. So, each class is like a box. I guess it's similar to them in functionality. But then when I move stuff around, I don't have to change the class name.

[00:30:49] JS: That's interesting. Okay, so my interview answer for – back to testing, my interview answer for, “Do you unit test is – do you do TDD?” It's always yes. And you can't answer with anything but yes. The reality is, like, only a handful people do TDD religiously. We know this. I don't know. Do you guys do TDD frequently with everything?

[00:31:17] Al: Yeah.

[00:31:18] T: Everybody is shaking their heads. What I want to know is the Venn diagram overlap between people who are sort of looking for, they do adhere to TDD, like, 100% of the time, and the people who tweet about doing TDD 100% of the time.

[00:31:35] JS: Oh, yeah. People who are posing?

[00:31:39] Al: Yeah, the people who tweet about TDD clearly don't because they have not written tests to test their tweet.

[00:31:48] Ar: The people who do, don't have time to tweet.

[00:31:52] T: Maybe the T stands for tweet, you don't know. [Crosstalk 00:31:57].

[00:31:59] JS: Oh, my gosh, Twitter driven development. That's good.

[00:32:03] Al: Yes, if anybody has any comments about that, @GloomyLumi. So, we're talking about CSS, we're talking about SaaS, and like scoping and stuff like that. But like, does anybody have a good way to like test components in a browser by themselves without making some weird amalgamation of multiple tools together?

[00:32:25] T: Are you talking about like, clicking through the app and seeing if it works?

[00:32:30] JS: Well, there's that.

[00:32:30] T: No. That was the segue to Cypress. I’m sorry. I ruined it.

[00:32:34] Al: There's like Storybook, right? So, you can make components in that. But then trying to get that hook, you have to like run a Storybook server and then like start an E to E thing, to click through that automatically. I don't know, it'd be cool if there was a way we could put those two together.

[00:32:51] JS: Yeah, that's what people do right now. They launch Storybook and then they hook Cypress end to end up. It's kind of bizarre, right? It's like, you have two tools and you're not even testing production, you're testing like, the Storybook Webpack render.

So, just the other day, I saw a component library, like boilerplate on GitHub. And it was like, “Here's how you use roll up to build your TypeScript component library, and then use Webpack plus Storybook to mount it into a development environment, and then use Cypress E to E to test it.” I was like, “What a terrible mishmash of tools.”

About a year ago, when I joined Cypress, I was hired to lead the component testing effort, and it had been going on for quite a long time. But it was only Webpack based. It was pretty slow because it was baked into the end to end test runner. End to end tests have always been slow. Cypress is a fast end to end runner, but that means nothing to component tests in Jest. People would not trade their component testing framework for Cypress when I joined. But very soon after we gutted the existing solution and we made component testing a first-class citizen at Cypress.

So, we integrated it very tightly and we got rid of all of the slowness. So, all of the like – if you've used Cypress before, there's this extra app that launches to let you launch your various browsers. In end to end people care about Firefox. People care about Edge and Chrome as their browsers. In component testing, we're just happy to use a real DOM instead of JS DOM, which is what ships with Jest. So, if you've ever had the polyfill fetch or request animation frame in your tests, we don't want to do that. That's not what a real browser does for your components. That's the strength of Cypress component testing, is we can do everything from capture file downloads, to alerts. So, there's really no need to polyfill anything in the browser. That's super cool.

I think going back to the mishmash, and your question earlier, Alex, was, “Is there a tool that lets you test your components in the browser?” And that's what we've been building. We re-architected the old solution that had been around for about two years at Cypress, and had never really taken off. We re-architected it and rebuilt it to be dev server based. So, the thing I'm most proud about is we launched a new beta, about three weeks ago, four weeks ago, and we haven't really publicized it. So, about the beginning of February is when we launched and we haven't publicized it. We're doing a very slow rollout. But it has support for roll up, it has support for Webpack, it has support for [inaudible 00:36:15] and that makes it lightning fast.

We went from 45 second startup times, which is what you get with Storybook, right? They’re Webpack based, you get a 45 second startup until you can do your component development. So, currently working with Storybook, because it's Webpack based, it takes about 45 seconds to launch and we were the same at Cypress in the original version of component testing, it took about 45 seconds to launch your Webpack dev server. And that's a pain you already feel. When you're doing app development, it takes however long it takes to bundle your application. That's the real cool thing about Cypress’s component testing, is that, we're as fast as your dev server. So, any optimizations or dev servers you may choose, we're going to be as fast as that.

So, in our original example, where people were using roll up to develop their component libraries, and Webpack to run their Storybook, we would just use their roll up dev server or the new hotness, we would use Vit, and that gives you sub one second startup in Cypress component testing. We actually rivaled Jest for testing. When you're doing TDD, when you're rerunning and changing your components, if you're doing style updates, or template updates, we I think we retest, like a medium size test, we would rerun in 650 milliseconds, and yeah, just takes about one to two seconds, depending on how cached it is, and how many modules you're loading. But Cypress, because of our dev server architecture, we're not re-bundling like Jest does, we are just using a combination of hot module reload and any dev server optimizations that dev server does.

For the basic small component, we're talking 130 milliseconds, but I've seen it lower. It's super cool. Usually you're just running one component test at a time anyway. So, that's really cool. And then like the power that comes with testing in real browser, I'm so excited.

[00:38:33] Al: That sounds really neat, because I definitely have – I've started playing with some Vit stuff and it's really like, it was uncomfortably fast. It would be really, really cool to go ahead and start integrating that sort of thing where I can just go, “Okay, cool. Let me test this component and do that testing in the browser with Cypress.” That would be amazing. So, I'm going to have to –

[00:39:01] JS: I will give you early access, and we can pair and we can hang out, and we can – I’d love to user test with you, honestly. We're just getting the UI a little cleaner and we're working on in-lining the dev tools into the browser, so you don't even have to have like Google Chrome Dev Tools open. It's just right next to your component.

[00:39:22] Al: That's going to be great.

[00:39:23] JS: It's really cool.

[00:39:25] T: I want to watch.

[00:39:27] Al: We're just going to have a special episode with me and Jessica going through a code base and I'll be like, “How do I – oh okay, this is really cool.”

[00:39:33] JS: It's so much fun. I try not to have a culture on my team, I haven't talked about this yet, but I got the really amazing privilege of hiring most of my open source heroes onto my team. So, yeah. In November and December, I got to hire [inaudible 00:39:53] who wrote Vue Styleguidist and helps maintain Vue Storybook. I got to hire him for component testing, which is all about being a development environment in your browser, honestly. And then I also got to hire my co-maintainer of Vue Test Utils, Lachlan, and that's just been such a dream.

We have such a great team. I think in total, we span I think four time zones and speak eight languages between all of us. Yeah, Lachlan speaks Japanese, which is pretty cool.

[00:40:28] Al: That's really interesting.

[00:40:30] JS: Yeah, he used to work in Japan. I started learning Japanese just so I can like maybe pair program with him in Japanese. But I'm still bad at listening, Tessa.

[00:40:46] T: I said, “do your best”, which I feel like, in English sounds like a lot of pressure to me, but –

[00:40:52] JS: I'm going to butcher the pronunciation, but it's Gambate. Oh, boy. That's how you say it is G-A-M-B-A-T-E, but I can’t pronounce it.

[00:41:04] T: So, one last thing I was wondering about with regards to Cypress was I remember when my team was looking at it the first place in 2017, one of the concerns that the test automation team had was that it seemed like it really only supported chromium style browsers and we had to support Internet Explorer. So, I'm wondering if anything has changed on that front?

[00:41:28] JS: No, and I don't think we're going to support Internet Explorer. My suggestion for people in any testing strategy, and I did this at my last job, where we had to support IE 8 until 2018. I would show up to like CSS workshops and people would be like, “Why can't you use Flexbox?” So, it was a mess but the way we got around code coverage for IE, and IE 11 was real time monitoring. So, if we threw errors, we would hit an API endpoint. And most of the time, what you need to test in your application is the functionality. If it works, if the components are actually doing the right things, and that’s, 99% you’ll catch in Chrome. And the only IE failures I've had are the bundle doesn't compile because you didn't polyfill this thing. Those are the only IE failures I've ever experienced while supporting IE 8 through 11.

[00:42:31] T: I think Internet Explorer was still supported in 2017, but not now.

[00:42:35] Al: Yeah, I think that Internet Explorer 11 still has support for enterprise through 2025. It’s still got a few more years for us enterprise people. But I know that in our company we have officially dropped support for it. My current company, we have officially dropped support for it.

[00:42:56] Ar: The other argument you can use is a security argument. Just be like, “Hey, if you guys care about the security of our app, you'll tell people that they can't use Internet Explorer.”

[00:43:05] JS: I think there's also like – now, there’s a same site cookie angle you can use with GDPR. So, there are quite a lot of ways to convince your manager. But all in all, even if you have to do it, you can still get coverage from chromium browsers for almost all of your users. I would suggest for many, many reasons to invest in real time production error catching, because the things that slip through are always the things you didn't write tests for. That some end user was able to get into a state with.

[00:43:41] Al: Yeah, we have real time error reporting, and it is perfect. I picked up one just the other week, it was great.

[00:43:50] T: Yeah, I think in terms of like, the place I was at, it wasn't so much that we wanted to support IE so much as like our customers couldn't switch off of IE. So, it's great to have an alternative support angle for people to take a look at if they're in that situation.

[00:44:05] JS: If you ever want to interview somebody with a similar situation, Lachlan came from that background. He had to write medical software that would calculate dosages. It's one of those pieces of software that you're like, “I cannot ship bugs.” And they used Cypress for all of their testing. So, if you ever want to talk to him about the challenges of convincing your boss to let you ignore IE 11 end to end coverage and pick Cypress, you can talk to him.

[00:44:35] Ar: That's fascinating to me, because I also currently work on healthcare software and because of HIPAA, that's why we don't support IE.

[00:44:46] JS: That's really interesting.

[00:44:47] Ar: I know.

[00:44:50] JS: Companies have quirks. They all have these strongly held beliefs that, I don't know, when you go back in time, it just all happened in a Google Doc in some meeting where they decided they needed to do it.

[00:45:03] T: Most times there isn't even a Google Doc.

[00:45:06] JS: Yeah. We have the problem of Zoom recordings being our source of truth. Our founder, Brian –

[00:45:15] T: Oh, no.

[00:45:17] JS: It’s rough. We really skew towards long meetings and we use a transcribing service.

[00:45:24] Ar: I was going to ask, do you guys at least get transcripts?

[00:45:27] T: Can you bring him on this show? I just want to talk.

[00:45:32] JS: You don't know what you're asking for. There's so much talking. Like all founders, he's very brilliant. I love him dearly. But it is an exercise to get decisions made concisely. It’s kind of – it’s a bunch of fun, though. Anyway. [00:45:54] Al: Cool. Well, I think that's good for this week. Jess, where can people find you on the internet?

[00:46:04] JS: So, I tweet a lot. So, you can find me on my Twitter handle @_jessicasachs. You can also find me at my talk in Vueconf US on Vit and Cyprus Component Testing. Vit actually doesn't really have a good component testing answer right now and we're hoping to solve that problem.

[00:46:28] Al: Awesome. Alright. And with that, it's time for us to move on to this week's picks. Ari, would you like to go first?

[00:46:43] Ar: Sure. My pick is Clubhouse Games on Switch. It is super fun to play with friends. Especially trying to play drunk darts. Just saying. Not that I've ever done that. Just theoretically, I assume it would be super fun. You can play by yourself or with friends. So, it is a pandemic. So, if you are being responsible, and you're by yourself, then you can still play.

[00:47:11] Al: Awesome. Tessa, do you have any picks?

[00:47:15] T: Yes, I have two. So, the first pick, we've talked on the show in previous pick sections about how I have hair. One thing that's really tough about having hair in the winter is static electricity. I have a bunch of different kinds of brushes, including anti-static brushes that work for a week and then stop working. So, I recently read that if you brush with a wooden brush, that would not add static. I was very skeptical, but I just got my brush with bamboo from the Zero Waste Store and it seems to be working very well. Actually, I feel like my hair is less staticky after I use it. Now, if that could be combined with a detangling brush, that would be perfect. But so far, I'm really liking that.

[00:48:00] Ar: Yeah, because I also have hair. It's very long now because – actually, no, I was growing it out before the pandemic, but we can pretend that that's the only reason why. So, it like the bristles are wooden too or just –

[00:48:13] T: The thing is wooden.

[00:48:16] Ar: Okay. I am in the market for a new hair brush.

[00:48:18] T: Bristle brush ASMR.

[00:48:21] Al: Tessa is showing us us her wooden brush.

[00:48:26] Ar: I'm going to have to try that.

[00:48:26] T: It's all bamboo and rubber. Yeah.

[00:48:28] JS: Zero Waste Store is amazing. I just ordered from them. I ordered a ton of stuff from there.

[00:48:35] T: Nice. Yeah. I like how you can offset your carbon emissions for the shipping too. That's pretty neat.

[00:48:40] Al: Nice. Jessica, do you – wait. You still have a pick. Sorry. I’m sorry.

[00:48:45] T: I guess Zero Waste Store kind of stuck in there as a half pick. So, my second pick, I haven't actually tried it yet. But I just got today, this three-dimensional game called the ThinkFun Gravity Maze Marble Run and it's basically like if you've played that game Rush Hour, it seems like it's very similar, but it's three dimensional. And given our XPath conversation earlier, it seemed like an apropos pick, despite my not being able to endorse it personally yet.

[00:49:17] Al: I might have to look into this thing because that sounds really cool.

[00:49:20] T: Yeah, it's also clear and colorful plastic, which I always love.

[00:49:26] Al: Yay. Jessica, do you have any pics for us this week? [00:49:30] JS: I do. So, my quarantine hobbies are gardening and anime. So, I have two picks. It's winter in Cambridge, Massachusetts. So, everything we grow dies, except for our arrow garden and I have – this is a podcast, but I have two giant bushels of greens. We’re growing like Bok choy and two types of kale and some greens I'd never even heard of, and they're like producing enough delicious salad, and my family hates salad. So, it's super cool. So, that's the arrow garden.

[00:50:09] Al: It sounds like a win win to me. You get to eat salad, and your family hates it. It's wonderful.

[00:50:18] JS: No, they hate most salad. But this salad is delicious.

[00:50:25] Al: Okay.

[00:50:25] JS: And it's satisfying. We also have a little herb garden with them, and we use all the herbs in drinks and stuff.

[00:50:32] Al: Neat.

[00:50:32] JS: It's really good. My second pick is my anime hobby. I think it's either Crunchyroll or Hulu, but there's an anime called Heaven’s Design Team and it's brand new in 2021. The premise is that God was supposed to make all of the animals and plants, and that was supposed to be the plan, but it was too much work, so he outsourced it. It follows this design team that is supposed to create different animals. It's totally like – if tech workspace was about creating like the giraffe, and all of the technical decisions they have to make about –

[00:51:20] T: Disrupts neck proportions.

[00:51:22] JS: Yeah, I mean, like – so then they talk about why the giraffe's neck is so long. I think it's like, and why it has, I'm going to mess this up, why it has like two stomachs because of the blood flow to its brain, and they like debug why the giraffe dies with different proportions. It's not actually like, gory. It's very cute. It's very, very cute.

[00:51:47] Al: That sounds really interesting.

[00:51:49] JS: I promise it's cute. They figure out how to make narwhals, and like, why the unicorn won't work functionally. It's super great. The unicorn is developed by the guy that made the horse who just cannot get over his original idea for the horse and he keeps trying to make variations of it.

[00:52:11] Al: So, he also came up with the zebra and the mule.

[00:52:13] JS: We just did the zebra. The zebra was an accident while somebody else was trying to get their design through. It's super good, I promise.

[00:52:24] Al: It’s like, think horses, but tigers.

[00:52:29] JS: I can go on, just watch the show. It's great.

[00:52:31] Al: That sounds fantastic. I'm going to have to check that one out now.

[00:52:34] JS: Okay, one more thing. The Galapagos Islands are their test grounds. So, when they’re trying to test if the animal will work, they go and they rearrange the Galapagos Islands into the proper environment and drop the animal there to see if it will live. It's very cute. Anyway.

[00:52:54] Al: Yeah, that sounds fantastic. So, my picks this week – alright, I have one pick, one pick. My wife may or may not have told me to say this one. So, there is a soda company here in Georgia that we have recently started getting craft sodas from. They're based in Athens, Georgia and they have a couple of really fantastic flavors. I really love their jalapeno, no habanero strawberry, and the butter pecan cream soda. It's like drinking a carbonated pancake. It's really fantastic. And for those of you who don't know, I don't drink, and so sodas are like my thing.

So, this company is based in Georgia. They have really good flavors. They also have a limited time flavor of their split banana cream soda. That is for the Savannah Bananas baseball team down in Savannah. So, the company is called New Creation Soda Works and they are delicious and wonderful and I highly, highly recommend them.

[END OF EPISODE]

[00:54:00] A: That's all for this week's episode. If you aren't following us on Twitter, head on over and find us @EnjoyTheVueCast. Be sure to subscribe to us in your pod catcher of choice, and if you have some time, leave a review. Finally, remember, the first rule of Vue Club is tell at least five or six colleagues about Vue Club. Thanks for listening and until next time, Enjoy the Vue.

[END]