Paul has a tutorial on testing and TDD with React and TypeScript. We discuss workflow and the differences, similarities between testing with React/TypeScript and Python.
Transcript for episode 167 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:00 I know how to test Python stuff. I don’t know how to test run in stuff like React, type, script, etc. But Paul Everett does. Paul’s here today to teach us about the joy testing, React and TypeScript.
00:00:27 Welcome to Testing Code. Good.
00:00:37 Well, Paul, thanks for showing up a test and code again. I think we’ve had you on at least several times before. Maybe once. I don’t know.
00:00:45 It’s a joy. I was going to say it’s great to hear your voice again, but I hear your voice all the time.
00:00:52 Like in nightmares or something.
00:00:55 No, my therapist could fix that part.
00:00:58 I’m sorry.
00:01:00 Well, it’s a joy to have you. So as a reminder, if people don’t know, you’re still working with Python, right?
00:01:07 Yes. I’m a developer advocate doing web and Python stuff at JetBrains. Great gig. I don’t know why they pay me. I should be paying them, but don’t tell them I said that.
00:01:16 So web stuff and that’s kind of what we’re talking about today. Indeed.
00:01:22 Are you spending, like, most of your time with web things now, or how would you say that?
00:01:29 It’s an interesting point. The thing that interests me, I got a confession to make. My wife was out of town this week, and on Saturday, I spent, I’m not kidding, 11 hours writing Python code.
00:01:44 Oh, how nice.
00:01:46 I’ve had for two years. This project about actually, it’s related to this topic about bringing modern front end practices for web development to Python.
00:01:58 Okay.
00:01:59 And it’s just an expiration. I don’t expect anybody to actually buy what I’m selling, but it is quite interesting to me, the both innovation and catastrophe that’s happening in the front end space.
00:02:16 Well, what do you mean?
00:02:19 I know there’s a lot of innovation that’s like constant, right?
00:02:25 Yeah. There are interesting things related to how you compose applications, Immutable, state trees and things like that and innovation in testing. And maybe we can talk about some of those things.
00:02:40 It’s just pretty you and I made a joke before about sparking joy, the kind of housekeeping you have to do, the rate of churn, the fatigue. They talk about those kinds of things when you come back over to Python. Those 11 hours that I spent, every second of every minute of every hour was in a test.
00:03:03 I did my typical code on the left, test on the right, test runner at the bottom, and coming back over to Python testing is just so joyful.
00:03:14 I love that. That’s nice.
00:03:16 Yeah.
00:03:18 One of the things I’ve noticed recently is we were in a land of, like, Python two versus three for a long time.
00:03:26 And now we can say it’s three now. Just live with the people.
00:03:31 But now it’s like. Yeah, but it’s not really just three. I don’t really want to work with, like, anything older than three nine.
00:03:39 That’s a good point. Maybe some of the packages and some of the things that you and I both adore just within the last week, I would think Hennock, for example, truck log maybe did an update and said goodbye. Anything older than 36?
00:03:59 Yeah.
00:04:02 And part of that, I think, is the F strings were great. So we kind of need those everywhere.
00:04:08 But that’s just it. But it’s not really like we’re breaking. I think that’s a different thing with application. So obviously with a package that’s being used by other applications and other packages, you have to be a little more mindful of that. Or maybe you should be.
00:04:25 But with an application, you’re the end user. You’re the end application.
00:04:31 You can say, for my application, I’m only doing 310 or 39 or whatever.
00:04:37 In fact, for my thing that I worked all weekend on, a couple of months ago, I pulled the trigger to switch to 39 so that I get easier type in so I don’t have to import list and all that stuff. Yeah, I was tempted to switch to 310 so that I didn’t have to do optional. I could do pipe to none, but Black doesn’t support 310 yet.
00:04:57 Oh, really?
00:04:59 Okay, I’m with you on that.
00:05:02 You make a good point.
00:05:03 These things that are happening for a class of people.
00:05:07 It’s Bark Troy.
00:05:09 Yeah. And then I was actually talking to Brett Cannon not too long ago and about the kind of the role of a maintainer of an open source project.
00:05:20 He was saying, Dude, it’s your thing.
00:05:24 If you’re maintaining it, you can say, I only want to test on 38 and 39 and 310. So if you’re using something older, sorry, it’s really up to the maintainer and the maintainers. And that seems harsh. But at the same time, open sources.
00:05:45 I’m doing this in my free time and my weekends and evenings.
00:05:49 If I want to use the new stuff, I can use the new stuff.
00:05:52 But anyway, he gave a keynote at PyCon.
00:05:56 Pycon. It seems like four centuries ago, but four or five years ago, it may have been the Python where you and I met when you gave your first talk, but he gave a keynote about just the drain of open source and that we all got to be nicer to each other and not be so drive by crappiness.
00:06:17 Right.
00:06:19 It is a wonderful talk. And then he’s talking more recently about things like just you got into doing open source because you wanted to share something. Don’t make it a burden.
00:06:32 There’s an implied contract that you’re supporting the world, but it’s not there. You don’t have to. Yes, but anyway, we’re digressing and going off on a tangent, which is fun to do, especially over beer my Mo.
00:06:47 Well, let’s get back to testing in JavaScript. So we’re thinking about like you can’t get away from JavaScript even if you want to.
00:06:58 And I guess you could. But a lot of applications, even heavy Python back end applications, there’s quite a bit going on in the front end and actually, in a lot of applications, there’s a huge amount of business value in the interactions that are going on on the front end.
00:07:15 I don’t know how to test that, but you do. So let’s talk about that some.
00:07:20 That’s a very good point.
00:07:23 Let’s face it, the UI is sexy.
00:07:29 It’s got a nice swagger, open UI on it. But the business folks are like, hey, Where’s my dancing donkey or something?
00:07:39 And how do you know that your dancing donkey still works after you’ve done the latest release? After your 2000 NPM dependencies have been updated? Because that’s the price these days for doing a modern React application.
00:07:58 Testing has an interesting, at least from my perspective, an interesting relationship to the world of front end development, particularly as someone coming from the world of Python and the culture of testing in Python. I find it fascinating. I’ve learned a lot in both directions, and I think that it’s worth talking about on test and code.
00:08:24 Yeah, definitely. Now, have you done any Ruby?
00:08:29 No, we’re not talking about that, and I haven’t either, but I know that Ruby is at least I’ve heard that Ruby is prolific. The entire culture is around. There’s a lot of testing in there.
00:08:42 Very good.
00:08:44 I think we like to test things in Python, but I don’t think it’s as much as Ruby that’s interesting.
00:08:51 I wonder when they put a testing library into, like the standard library.
00:08:56 I wonder if it was baked in earlier than Python.
00:09:00 Yeah, I’m not sure we should get some Ruby people on.
00:09:03 All right.
00:09:04 But React and we’re not just really talking about JavaScript. Really? You’re talking about React, right?
00:09:14 Or are you talking about JavaScript?
00:09:16 Also, some of the complaints that I will have are primarily aimed at React and maybe Angular, these ecosystems that have just gotten colossal as far as footprint on number of applications to do Hello World, number of dependencies. Sorry to do Hello World.
00:09:38 There is a change coming in the world of JavaScript, and it’s going to feel different within the next year where native module support will be a thing and people won’t be using bundlers as much.
00:09:53 Okay.
00:09:55 And some changes then in frameworks so that you type three lines and the test runner runs and your CPU fan goes because it’s like transpiling 2000 NPM packages.
00:10:10 And so when that gets cut out of the loop and some things go on a diet, it will be a little bit more joyful. But the message that I give in that tutorial and the message that I’ve talked with you about is I’m about the joy of Tesla.
00:10:31 In fact, it will remain nameless one of the three or four people on Twitter that I pay attention to deeply just tweeted today about.
00:10:42 They kind of treat tests as receipts at the end of the project to prove that the work got done.
00:10:50 It does not spark joy for them, and I understand that point of view, but for me, especially in front end development, it’s about joy.
00:11:00 And if we have a chance, I’ll kind of dive into that.
00:11:05 Actually, yes, we should. But you mentioned a tutorial, but I don’t think we mentioned it yet.
00:11:12 Oh, my apologies. Yeah. So I have a tutorial at the website for Pycharmguidejetbrains.com. Pycharmguide. I have a tutorial on Pi test, and using PyCharm is kind of a Gui for Pi test.
00:11:29 I have another one in the Webstorm guide on React TypeScript and TDD.
00:11:38 Okay.
00:11:39 Which sounds like the three Horsemen of the apocalypse, but it’s something like a twelve part tutorial with videos and code and text explaining this kind of way of working that I find joyful that I don’t even want to call it test driven because it’s more like test first. Why? Because it’s a more productive environment to sit in my test than it is to type some stuff, go to the browser and click the universe.
00:12:09 Yeah, definitely. That’s cool.
00:12:16 So you’re running tests that are driving a web application in that environment. Is it headless at this point, or does your browser pop up?
00:12:29 Very good and important question.
00:12:32 Some of the front end frameworks like Angular with its test runner called Karma, are really more about a test runner that fires up browsers even like the headless Chrome driver thing, but it’s still Chrome out of the box with React, I should say create React app, which is the official scaffold.
00:12:55 You get something called Jest, and that is the dominant test runner. It’s like pytest.
00:13:01 Okay.
00:13:01 pytest isn’t required for Python. It’s just everybody uses it. And I heard something about an update to a book that’s like the canonical Bible for Pytech. Yes, Jest is different because you don’t execute your JavaScript code in a browser’s JavaScript engine. There’s this fake JavaScript interpreter called JS. Dom.
00:13:27 Okay.
00:13:29 And it runs in Node. Js, which is like a Python interpreter rather than a desktop GUI application called a web browser.
00:13:38 Okay.
00:13:38 That’s the secret to making this stupendously productive. I don’t contact switch over into this other thing called the browser, and I can set a Breakpoint and I can stop at that Breakpoint. And it’s in my IDE. It’s really close to my environment.
00:14:01 Okay. And when it’s running this JS test, is that what you said?
00:14:09 When Just is running?
00:14:11 Is it necessarily something that you have the JavaScript isolated, or does it talk to databases and services and things like that?
00:14:22 That’s another thing that’s been an interesting learning experience for me, coming from the world of Python testing to the world of front end testing in Python, there’s a lot of different churches of thought about units versus integration versus end to end, et cetera.
00:14:42 In the world of JavaScript, it is much closer to integration.
00:14:48 Okay.
00:14:48 The culture is much more about go ahead and bring in the whole thing and render that button, but still, go get everything. Don’t try to mock everything out, get it the way it would be for the user and make some assertions.
00:15:07 There’s this other part called Indian testing. Cypress is the dominant tool for that. And that’s about executing and browsers to make sure that you haven’t failed in this version on that operating system.
00:15:20 Okay, how about on the database is the database side? Is that more of like the end to end stuff?
00:15:28 Well, that’s an interesting point. It’s the third rail that I’m currently adamantly staying away from, which is server side JavaScript.
00:15:39 So in browsers, you’re not going to open a database.
00:15:44 Right.
00:15:44 You’re going to talk to an end point that opens a database.
00:15:47 Server side JavaScript would open a database.
00:15:51 Okay, so you’re talking to an end point.
00:15:54 Is the end point mocked or is it.
00:15:57 Yeah, the endpoint is mocked.
00:15:58 Okay, cool.
00:15:59 They have a pretty good mocking strategy. And it’s interesting because as friend of the show and friend of you and me in real life, Anthony Shaw wrote a blog post within the past two weeks about I stumbled across async Pytost. Here’s a blog post for how to make it work.
00:16:22 So it’s a little bit tricky if you’re an old school Pi test person to make the jump into pytest. Well, that’s all over the place in front end stuff. And so things like Test and Code, React, testing library have all kinds of assertion helpers to improve the ergonomics of that.
00:16:43 Okay, nice.
00:16:44 So I don’t know if we covered it yet. You wanted to talk about your joy of testing.
00:16:51 Sure.
00:16:51 Is there more that you want to talk about?
00:16:54 Well, what I found in writing that tutorial and then the work I’ve done is like in the tutorial, there’s several really long sections about, okay, we’re going to refactor this from a big component to a parent component and a child component. We’ll change our test and update our type script and all that. We do all these steps and we had an event handler for clicking the button and we pass it between and we get to the end. And I remind the audience, guess what? You never looked at a browser.
00:17:26 You stayed in the IDE the entire time.
00:17:30 You stayed in the flow and everything was using things you already know. And it just felt familiar and controlled.
00:17:41 And you’re just working methodically.
00:17:44 That great feeling you get in Pi test when you’re just going bit by bit and working methodically. And so that joy of testing thing is less about what’s my coverage number and it’s more about, hey, I want to make this thing work.
00:18:01 What’s the most productive way for me to stay in the flow?
00:18:06 Yeah. Okay.
00:18:07 And that’s something you can do with the React and Jones.
00:18:15 That’s right. With this stack. And I mentioned briefly about TypeScript, which is a divisive topic in the front end world.
00:18:27 But for me, I get the joy of testing when I’m in the right hand side I’ve got my test code, and in the left hand side of my IDE, I’ve got the code that I’m writing.
00:18:39 So I’m like a consumer of my own code. I’m consuming the API of the component that I’m writing.
00:18:45 Okay.
00:18:46 If I see TypeScript, I get little red squiggles. When I do something wrong, I fail faster.
00:18:53 So remind me what types of script is.
00:18:58 You should think of it exactly like Python type hinting. So for people in the world of Python, for the longest time there was type, there were types. You just didn’t have to type the types. Yeah, but around Python 36 time frame, they’re starting to become not just a syntax, but a culture of write down your types for things that people are going to consume.
00:19:27 That’s a good way to put it.
00:19:30 Which might actually be you six months from now when you flush the whole damn project out of your brain and you can’t remember a line of code.
00:19:38 Also in Python, a variable can switch types because it’s not really switching types.
00:19:45 It’s just pointing a name that’s pointing to something else that happens to be a different type.
00:19:51 And with my pie or something, we’re going to test to make sure that that doesn’t happen. If we say it’s a list event, it’s always going to be a list of INTs.
00:20:03 Indeed.
00:20:09 And that’s one of the things that I like about adding types when I know it’s not going to change. Sometimes I don’t know what the type is going to be, so don’t put a type on.
00:20:18 Yeah. And when you do all of this in a smart editor, and at this point, I would say probably 90% of the market for editing in the world of Python 80 90% now uses typing between Pi Charm and the Language Server for Pylance pyrite. I think Sublime Text is adopting that as well.
00:20:48 Okay.
00:20:48 It means your editing experience, your developer experience tells you immediately when you got it wrong.
00:20:57 And on Saturday, I can’t tell you the number of times Pi Charm squiggled me. I’m like Pi Charm. What’s your. Oh yeah, you’re right, you’re right. Again, like you were the previous 1000 times.
00:21:10 Yeah. And actually, that’s an interesting thing.
00:21:16 Is TypeScript a similar sort of thing?
00:21:19 In Python, the types are optional and you can ignore them and just don’t follow them.
00:21:29 Typescripts or someplace in between gradual typing, which was the original pitch for Python typing.
00:21:35 Okay, how about type of time?
00:21:38 There’s also a little bit at a time. It’s optional. You can do more.
00:21:45 There are different flags, just like there is with my pie about being strict and requiring it everywhere.
00:21:51 Okay, how about like changing types?
00:21:54 If I say name is a string but I assign 32 to it, will TypeScript allow that or will it blow?
00:22:03 Okay, just like Python.
00:22:05 Well, Python allows it once you’ve assigned a variable and then later on if you try to assign it to something else, it’ll get mad. I mean, it will allow it at runtime, but the type checkers will get mad about it, right?
00:22:19 That’s what I’m saying. But TypeScript isn’t just about the type checkers, right? It’s a runtime.
00:22:26 Actually, it’s less runtime. Even Python. Python keeps the type information at runtime in the Dunder Annotations type script, much to my chagrin, throws all of that out.
00:22:40 Okay, well, I think now I’m the problem of going off on a tangent. Let’s bring it back to some of the cool stuff and some of the lessons. Is there anything from JavaScript testing that maybe we could learn and use in Python?
00:22:58 I will talk first about kind of the whole developer experience, mainly because this has occupied a lot of my thinking in the past couple of years.
00:23:12 Awesome.
00:23:13 That I’m writing code and I have better tooling available than I did five years ago and maybe I can put it to work to have a better development experience. So in the world of JavaScript, like React, et cetera, you’re using one of these IDE smart Editors, and as I’m writing my code, it’s autocompleting, it’s refactoring. If you give it more help by saying, here’s the interface for the props for my component, the arguments that I’m going to supply to my component, then it will autocomplete on those and tell you when you got something wrong and give you refactoring tools. And then that all comes over into testing. As I’m writing my test, I’m accelerated.
00:23:59 That whole development experience I think is interesting for Python, both in the code we write and the tests we do.
00:24:10 How to get a better development experience thanks to typing and fast, API is pioneering this with putting tight hints to work for you to have a better development experience.
00:24:29 Will with Textual is doing that.
00:24:33 And then SQL Model, which came out last week, is doing that as well. And Sebastiano has very explicitly said he went over to the world of front end development, looked at what was available for developer experience there, and wants to have more of that in Python.
00:24:53 So this kind of whole view of I’m sitting in a smart tool, I’m writing code, I’m writing tests, I’m executing them. How can I have a better development experience is something that I’ve learned from in the front end.
00:25:09 Okay, that’s neat. I didn’t know you could do that with front end stuff like front end stuff.
00:25:17 As you would expect, there are many ways to do it. And probably during the recording of this conversation, someone will release a new testing library, which is frustration and leads to the fatigue aspect, but it also means there’s a lot of innovation.
00:25:37 Okay.
00:25:40 The React testing library from Kent Dodds is really interesting reading and it itself innovated in the middle of its life and had a little bit of an overhaul. He is very focused on ergonomics, trying to get you to write a test that looks like how your users would use the software.
00:26:06 Oh, that’s nice. Yeah, that’s how you want to write a test.
00:26:10 It seems so obvious on the face of it. And then when you see his take of assertion, writing and things like that and what to test and what not to test, it becomes kind of, oh, wow, there’s a lot of thought that’s gone into this.
00:26:26 That’s cool.
00:26:30 So what do you mean by seeing is that by looking at the way that the test framework is put together.
00:26:36 Can you explain again.
00:26:38 You said when you see how he’s dealing, like thinking about asserts. Is that because the Test framework has different assert methods that are useful?
00:26:47 Indeed, it is a testing library with adapters connectors that make it work with React or Angular or this thing or that thing, or the other thing. And there’s an assertion library that’s common to all of them. And then there are custom assertions for specific things and kind of the flow of it. If you think about writing a test for the story points in a browser UI, it’s a lot different than what we would think of in Python.
00:27:19 It’s like, go get this page.
00:27:22 Wait for it to stop rendering.
00:27:25 When it does, go find this little bit of the we’ll say Dom the component.
00:27:33 Just wait for it to finish its lifecycle. Click this button.
00:27:37 But mock up this event handler first.
00:27:41 Wait for it to do its thing, watch its transitions as it changes state, and then if it throws an error asynchronously catch it.
00:27:54 This whole event driven approach is like writing a Gui application and testing a Gui application.
00:28:03 Okay, that doesn’t sound fun, but it is fun.
00:28:07 It actually becomes fun now that we are like ten generations into learning lessons in the world of front end testing. And you have some of these frameworks that simplify the problem, focus the problem, and then make some asserts that make the common cases easy.
00:28:29 Okay, cool. So I’m looking through some of some of the stuff. At least. I’m actually looking at a blog post. It’s like a tutorial for it.
00:28:42 Testing library.
00:28:44 One of the things I do like I’ve noticed so far is that you can have meaningful tests, still be fairly short. You can see them in a half a page or something.
00:28:55 Sure.
00:28:56 So that’s nice.
00:28:58 And that comes back to those adapters I talked about where they have to assemble the running application and get the component into a Dom, basically transparently so you don’t have to and think about it. If you’re writing in TypeScript, you’ve got to convert all of that into JavaScript before executing it. So you’ve got to take a path through the transpiler in order to execute yourself.
00:29:26 Okay, so is this a long, like a lengthy process? Are you waiting seconds? Minutes?
00:29:33 Milliseconds?
00:29:35 Indeed. That is maybe number two on my list of things that do not spark joy in JavaScript testing. The other one being if I write some tests, like I’ve got a big the website that we talked about, PyCharm Guide. Webstorm guide actually written in JavaScript for this thing called Gatsby.
00:29:57 If I walk away from test and code back three months later and run my tests, and if I update the dependencies, if I update the dependencies, run my tests, I have no confidence that they will work.
00:30:11 That’s my number one complaint is that it’s just total chaos in trying to keep up with things, especially if you mix TypeScript into the equation. But the other one was, man, these tests take forever to run.
00:30:27 No kidding. They’ve got 2000 dependencies to transpile.
00:30:32 Okay, but what do you mean by a long time to run Hello World in react.
00:30:43 You should expect that to take like two or 3 seconds.
00:30:49 Okay.
00:30:52 Yeah. You’d want it to be faster?
00:30:55 I’d want it to be faster. Yeah.
00:31:02 I guess. I’m jaded. I work with test equipment, so I got to wait for settling times and things like that anyway.
00:31:10 Sure.
00:31:11 But I know that a lot of people want to test the whole world really quickly. That’s another thing that varies with at least in the Python environment that I’ve seen, I might be developing. So I might have a test suite and who knows how long it takes, even if it takes like 30 seconds. I’m not running it all the time.
00:31:31 I’m zooming in and testing a small portion of the feature that I’m working on and modifying, and then I might actually be a bad boy and not ever run all the tests. I might just push up the merge request and see what the results are because the CIO run them on all merge requests.
00:31:53 Now, is that a similar sort of thing in the JavaScript space? Or people splitting up their test suites and during development, running a subset and then pushing up more?
00:32:06 That’s a good question.
00:32:10 The segment of tests that are end to end. When people do end to end testing and they run them in actual browsers locally.
00:32:19 That’s an interesting candidate for outsourcing to a hosted service that has all of those browsers installed and obviously executing edge on Windows. I’m not going to be able to do so. That is a thing.
00:32:34 My feeling is that first, I don’t believe that testing is adopted nearly as highly as it is in Python, but I probably have an overly optimistic view of Python testing culture.
00:32:55 Well, yeah, maybe you do, but we also need to kind of define what we mean by testing. I bet it’s all being tested, but I’m sure you mean automated tests.
00:33:04 Automated tests, yeah, something running in a test runner, and so I don’t think people are segmenting them the way that you’re describing it. I rarely see a discussion about that.
00:33:16 Okay, interesting.
00:33:20 But in that sense, people really do want it to be faster because they’re running everything.
00:33:26 Okay, so that two to three second thing that you mentioned with Hello World, does that exponentially increase for a larger application or is that pretty much you’ve got like a two or three second tax on all tests?
00:33:40 It’s the latter.
00:33:42 Okay, so then is the second time I run the test, is it transpiling everything again or yes. Oh really?
00:33:51 Okay.
00:33:54 You were also mentioning that maybe some of the stuff might speed up within the next year.
00:34:00 Sure.
00:34:01 As we move away from bundlers, as we move away from huge frameworks, there are a couple of JavaScript ecosystems spell solid JS, some others that are thinner and are closer to embracing native es six ECMAScript modules which work in the browser and until recently behind a flag in NodeJS they would work. So now that’s all settling down a little bit. Some of the frameworks are adopting it and you have less that needs to fall under that bundler thing. Now if you’re doing TypeScript it’s going to have to run through the TypeScript. Compile.
00:34:47 Okay.
00:34:48 But you definitely said to you you’re not seeing as much testing in the JavaScript space. But there’s obviously some because Kent made that library and all that stuff. So some people do testing.
00:35:04 It seems to be aimed a lot at framework and library owners rather than business application writers.
00:35:12 Well okay, that doesn’t surprise me because the framework people are doing this stuff for free and they can’t hire people to manually test it.
00:35:23 It’s a survival tactic.
00:35:25 I just wish that more companies would realize that and hire actual engineers to do tests instead of anyway.
00:35:36 But this is fun. I don’t know if I got a full picture but I think I got a glimpse and hopefully the listeners also got a glimpse of what it’s like to be a joyful JavaScript test developer or test person developing. I don’t know, front end stuff. Sure. Indeed.
00:35:55 So thanks Paul and thanks for having me on. Thanks for continuing to do Test And Code and hopefully I can come back sometime and talk about JavaScript testing and everything that I said that was changing in the world of JavaScript will have happened and it’s a lot better.
00:36:14 Welcome that that would be great.
00:36:23 Thank you Paul, very informative. Always enjoy talking with you. Thank you Patreon supporters for supporting the show. Information on how to sponsor or support the show is at testandcode.com support. The link to Paul’s tutorial is on the show notes at testing.com one, six, seven. That’s all for now. Now go ahead and test something.