Fire-Side Chat with Kent C. Dodds

Hello! Hey Kent, how are you doing? I'm doing great! It's a beautiful morning here in Utah, kind of rainy, but my wife likes the rain, so I'm happy. Happy wife, happy life! And of course happy kids with managing four kids.

Yeah, like I said, crazy managing that with your career. Yeah, they're great! I know that you are really happy with your kids, and I'm also happy with my kids of course, but how are you managing now with the pandemic? They're probably more at home and managing your career is that difficult or is it okay now? You know, I was already doing a lot of remote stuff before the pandemic hit, lots of remote workshops and things, and so the pandemic didn't really impact my career a whole lot in that regard. I mean everybody was impacted and my kids started doing school at home and everything, so it shook everything up, but yeah, I wasn't impacted as much as everybody else. Good to hear that. So, as much as I would love to talk about your kids, I also have a son, and yeah, like to talk about it, I think our audience is not here for talking about your kids. They want to talk about testing, and so a few weeks ago we've sent out a tweet that people can ask some questions that they want us to discuss, and the first one is from Peter Hozak.

You are migrating some of your projects to TypeScript. What are the biggest pain points for you so far, and what can you recommend to the people or teams who are not yet decided whether to start the migration in their projects? How time-consuming would you say it will be?

Ooh, so it will be relative to the size of your project and the experience of your team, so I can't really tell you exactly how time-consuming it would be. Migrations are always really tough. You have to take that with a grain of salt. I actually have a blog post about engineering and business alignment and how important it is that you do what's best for the business, not just what you want to do. It's actually a pretty good blog post. You can go take a look at it at kentcdots.com slash blog.

As far as recommendability, I definitely recommend it. I think it's a great idea. There are some strategies that you can use. To be clear, I haven't ever... I'm trying to remember. I think we actually did migrate one of our projects at PayPal to Flow. That was in process as I was leaving. But here are a couple of tips. First off, it doesn't have to be perfect, especially if you're just learning TypeScript. So I would not turn on strict mode. It's actually similar to adding ESLint to a project that's never had linting. I wouldn't recommend it enabling all of the rules and fixing it all in one giant PR, but rather disable most of the rules, and then over time, you add them as warnings, and then you fix things here and there, and then you turn them on as errors or whatever. So in the same way, just make your TypeScript really loose at the very beginning, especially if you don't know TypeScript very well. You don't want to just spend a ton of time writing your types, and they end up misleading you, and you write it poorly because you're new at TypeScript. So throw an unknown there, throw in any here, whatever you need to do to get it going, and then come back later when you know TypeScript better. So yeah, I would recommend it. I would recommend it iteratively over time rather than just one giant PR, but yeah, I think it's a good idea.

Yeah, that's also my experience. Going with a Big Bang, I mean, besides that it just takes a lot of work from you, you're going to send that PR to someone and he's going to be your arch enemy after that, right? If you want to keep friends with your colleagues, then don't do the Big Bang, even if it's a small project, like Migrant TypeScript, even though it's really valuable, it is a lot of work and yeah, don't go with the Big Bang strategy.

Next question. What a different story. You're getting Big Bang prettier all day. Next question is from Behzad.

Nowadays, that Next.js looks so solid, should we use Next.js instead of Create React App or Create CSR? I'm not sure what CSR is, but yeah, so Next.js is solid. Sorry, I'm going to stop for a little bit and I want you also to chime in if we're going on Next.js on the vendor login.

Oh yeah, sure. So, yeah, Next.js is solid. I used it years ago, I haven't actually used it recently, but a lot of people use it and they love it and yeah. So, I don't think that you can go wrong with using Next.js as a framework. I'm really, really excited about Remix personally. For the last several months I've been using it to totally redo my personal website. I'm really excited about a big rewrite that we are working on. So, that's what I'm working on, but it is still developer preview. It has features that you won't find anywhere else and that's what's compelling about it for me. It's not just like a paid version of Next. It's very different from that, although a lot of people like to say that, without any experience with Remix. But Next is totally solid. If it looks interesting to you then go for it. Do you have your Remix project in production also already or is it in development still? It's still in heavy development right now, but we're talking like a month or two before it comes out and it'll be pretty sweet. Nice! Well, looking forward to that. Probably you'll announce it on your Twitter and all your channels of course. Oh yeah, you won't miss it. If you follow me on Twitter or like or subscribe to my newsletter or something, you will definitely hear about this. Yeah, I know when you do something new that it's hard to miss. That's a good thing. Because I always like to see what you're doing. Wouldn't want to miss it for the world.

Next question is from Carlos. Is the testing library a new mindset for front-end tests? I mean, we don't think about user behavior, so maybe it's not to test some component like a button or even a hook and test it integrated in a page. It's more like a side-press test, let you really go into a flow. Yeah, so I don't often test lower level components that don't have very much logic into them because it's so easy to cover those things. If you have a little button or something, I got you would not find me testing a button unless there was some fancy complicated logic that I wouldn't easily cover in a higher level test.

I have a blog post about this as well. You can find it at kcd.im slash trophy, where I described the different layers of the testing trophy. One thing that I say in there is actually I'm quoting an interview that's on testijavascript.com, where it's basically testing. These different layers of testing are kind of like painting a wall. The quote is, you can throw paint against the wall and eventually you get most of the wall, but until you go up to the wall with a brush, you'll never get the corners. Your end-to-end test, that's like just taking a bucket of paint and throwing it at the wall, but eventually you need to go with more fine grained tests. Maybe you've got a painting that your grandma made it or something, and you don't want to even paint with a big brush. You'll take a smaller brush around that. That's kind of the way I think about different layers of testing. There's no reason to take a small brush to paint the entire wall. It will take too much time to get full coverage. But yeah, I focus more of my time on integration tests like that, so paint roller. You cover most things really well with that, and certainly end-to-end tests as well, but you can use testing library for all of these. That's the cool thing about testing library. Anywhere DOM can be found, a testing can help you to query for elements and interact with those elements.

And you were mentioning coverage. And I don't think there is a real answer to this, but we can ask it anyway. See what your thought is. What's a good coverage for most projects, you would say? Would you always say 100%? 100% or… I actually would assert that 100% is a bad coverage number. And maybe not as bad as 0%, but yeah, still a bad one for most of the time. Now, if we're talking about an open source library, then yeah, sure. 100%. That's typically relatively easy to accomplish. And there's a high value for that, because this is highly reusable code. So, it's a little bit different.

But for applications, if you're shooting for 100% coverage, you typically end up spending a lot of extra time testing things where you'd get a higher return on your investment working on features instead. And so, I actually have a blog post about this titled How to Know What to Test. And in that, I kind of talk about how code coverage is a useful metric, but a better one would be use case coverage, which is not really reasonably easy to set up as a metric, but it's the way that you should think about your test.

So, I don't often look at my code coverage report. The only time that I look at that is just to remind myself of use cases that I may not have covered, but I'm always thinking about use cases. What I really like about... Well, it's not actually about the coverage, but if you look at that report, I think it's the Jasmine report, it's called, where you see your code and then what branches are not touched by the code, by the tests. That is a way I really like to go through that and see, oh, wait, this is a path that is dangerous that I didn't test it, and then I'll test for that. Yeah, exactly. So that is a good thing. And yeah, like you said, going really for 100% or whatever the percentage is, I've had companies where there was a percentage set, and you just know that at a certain point, you were going to be writing tests just to satisfy your coverage needs, even though you already know, this is fine. I don't need to test it, but yeah, my pipeline will fail if I don't that test. So yeah, but don't go there.

Next question is from Henrik. What's the best piece of advice that you've received career wise or also in general? What advice would you give now to someone who's in the beginning of their career in tech? Great question, Henrik. Yeah, that's an excellent question, Henrik. So I think one of the most important things, the first thing I have to say is to be nice. It doesn't matter how good of a coder you are or how good of a, you know, people, well, yeah, you just got to be nice. If people don't want to work with you, then you will not get the work that you want. So if you want to have control over your career and really accomplish whatever goals that you have, you will be able to do that much better if you're a nice person. So then on top of that, I would say communication is a really important career skill because even if you are the best coder in the world, if you're not good at communicating what you've accomplished and how that impacted the business or improved lives for people, then that also will make it difficult for you to get the work that you want. You see this often with people who are really good at something or at least they're the one who doesn't complain about doing something and so they get all of that work when actually they'd want to do something else. So you need to be able to communicate what your career goals are and what your accomplishments are. You just get really excited about the things that you want to keep doing and you say, hey, look at this cool thing that we did. I'd love to keep doing this or hey, this is a cool thing that we did, but I'm not super into that. Could I start doing some more of the front-end side or the back-end side or whatever? So communication has been a really, really useful tool for me. Yeah. I love that you're saying that at a tech conference, that you don't mention any technology, just be a nice person and I love that answer. Thank you. I'm going to go look at our Discord channel, what the input is from our audience, the live audience.

By adding testing for different locales, you can ensure that your application doesn't break. However, when it comes to testing right-to-left (RTL) functionality, it's a feature that you definitely don't want to have break. If RTL is critical for your business, consider using visual regression testing tools like applitools or perci.io. These tools use advanced AI to reduce the flakiness of visual regression tests. Netflix has shared their approach to RTL testing in a blog post, where they add extra characters to strings to ensure that the interface won't break when using languages with longer strings.

Regarding React Testing Library, it does get tested itself. Testing code is no different from any other code, and the tests you write for your code are just code themselves. React Testing Library is a collection of utilities that were initially created for personal use and later turned into a library to help others. It is mostly JavaScript utilities and is tested using Jest, which uses Jest to test itself.

Well, of course, there are a lot of businesses where it matters. The thing I know about testing RTL is the Netflix bullet post. It was like two years old, and they shared their approach that even when also doing a left to right LTR, that we're adding, I think 20% extra characters in every string, just so they kind of know for sure that if there's a language where the string is longer, that the interface won't break. So that's, I don't know if you've seen this blog post, but that's something, if you want to do RTL testing, I would recommend looking up on the Netflix engineering blog, which is also just a nice blog to follow.

Percy.io is the other one you mentioned. Question from Luke, does React testing library get tested itself? How do you test your testing library? Yeah, nice. Yeah, yeah, sure. Well, you think about it, testing code is no different from any code, any other code, like in fact, even the test that you're writing, that's just code. And you could write tests for those. You could take your, your test function block, you could put that in a function, and you could call that function and make assertions on what it does. So like, it's all just code. And when you're writing a bunch of tests, eventually you come up with some utilities that may or may not be useful for anybody else. And that's what react testing library is, it's a bunch of utilities that I wrote for myself that I thought, wow, these are really useful. Let's make a library out of it. And, and then teach people how to use it. And that's testing javascript.com. So yeah, it is definitely tested itself. It's mostly just like JavaScript utilities. And so it's not, you know, it's very different from a testing framework. But even the testing framework itself is also tested. That's actually even more interesting, because Jest uses jest to test itself. And so yeah, that's where things get a little meta. react testing library doesn't use react testing library to test itself exactly. I mean, we are calling render when we're testing the render function. We are calling, you know, get by text and stuff and get by role and all that stuff. To make sure that it's doing what it's supposed to most of the time we're in general, I recommend that your test should resemble the way that the software is used. And so our tests for react testing library do that as well. So if you go through the react testing library test, you'll probably find some that are for lower level utilities that are more lower level unit tests that you wouldn't write. But lots of them are integration tests. They'll look very similar to the types of tests that you would write.

And if our tests are passing, then we assume that we won't break your tests. Hopefully. Hopefully. Well, science is kind of scary. Like you said, Jest is using Jest to test their code because if Jest breaks, will the test also break? Yeah, how do you know that? Yeah. I believe that there are some languages that are written in themselves as well. I don't know how that gets started, but eventually they switch over to their own language to write their language in, which is interesting. That's extra meta.

We have a question from Sasha. Do you think integration testing is also important in addition to unit testing for component library? And how do you feel about integration testing in general? Yeah, well, I have a blog post that's pretty popular on this topic called write test not too many, mostly integration, which is a quote from Guillermo Rausch from years ago. And yeah, you can take a look at that. It's kcd.im slash write dash test. And so, the testing trophy is weighted toward integration tests. I focus on integration tests for component libraries. The line between integration and unit test kind of gets fuzzy. Some people say unit test is just the unit. You mock everything around it. And if that's how you define a unit test, then I don't write many of those at all. And most of those are like, I have a pure function. It's pretty complicated. Let's just test that by itself. And that would be my form of unit test. So, if that's how you define a unit test, then a component library, I pretty much wouldn't use almost any unit test. It would all be integration. I want to render the component. I want to interact with that component. And yeah, so, I focus most of my time in the integration space.

So, let's go a step beyond component libraries. Let's say you have a design system. So, just a collection of components in the end.

Would you also be adding tests for a design system then? Yeah. So, then you wouldn't be testing that button. Yeah. Yeah. And, actually, at PayPal, I was responsible for building that. That was the last thing that I worked on before I left. And yeah, I was testing every component. And, but there was always logic that I was testing there. And when it is like a design system or component library and you have a button, I would at least have one test that says, this thing renders because it's just so low cost to have that sort of a test. And because it's a reusable design system or component library, I wanna make sure that I didn't have like a syntax error or something. I mean, it was in TypeScript. So, the likelihood of having a problem is pretty low, but.

But then, would you say like a snapshot test would be enough? Yeah, snapshot tests. I have a blog post about this called effective snapshot testing. Yeah, in component libraries, maybe. The thing is that snapshots are just assertions. They're no different from any other assertion. So, when you have an assertion, you want to make it so that a failure, when you have a failure, you know why it failed as much as possible. That's your job as an assertion writer. And when you take a snapshot, you can take a snapshot of the world that could include where the sun is and what operating system you're running. Literally, everything. And this is the state of the world. That would not be a useful snapshot test. Of course, we don't do that. Often, I will see snapshots that are hundreds of lines long. What I'm saying is a snapshot often includes a lot of information that is totally irrelevant to the test. And so, I really rarely use snapshots for UI testing. It is very rare that you'll find me doing that. What I do is I'll, if I want to start with a snapshot, I will slowly get rid of all the stuff in the snapshot that is irrelevant. So, I'll find the element that I'm trying to assert on.

And then I'll realize, oh, all I care about is that this attribute is, you know, this certain value. And so, instead of doing a snapshot, I'll just make an assertion on that attribute. So, yeah, you can read more about that in my blog post about snapshots. Yeah.

So, if you actually want to, let's say we're going back to a button and you want to test if it accepts a class name, your component for that button, then you can do that with a snapshot, but if the snapshot test fails, yeah, you don't know what you're testing anymore unless you've written a really good description, so it's better to just say it should accept the class name and then, oh, I am failing with my testing library syntax in my head. I was going to write it. You just select the button and say to have class name and then it's very clear, like I pass it this class name, I expect it to have the class name. If that fails, then whoever's reading it, even if it's me in six months, I know exactly why this failed. I know exactly what the object is. I may not know why it happened, but I know what the intended outcome is. Yeah, that's a good point.

Sometimes even your writing tests for yourself. Always when I'm writing tests, I have a quote from a friend of mine, Frank de Jonge, and he once tweeted, I don't write tests, I write proof. And that's always, like I'm proving to myself that this works as I intended. And I really like that mindset for myself. So yeah, that sounds good to me.

Next, we have a lot of people mentioning, by the way, like Go is written in Go, C is written in C. TypeScript is written in TypeScript. So really cool to have that interaction. It's a little mind bending. It's too meta for me.

Juan is asking to follow up on the communication tip. What communication resources would you recommend? Nice. Thanks, Juan. Practice, I guess. I don't have any resources to offer. I'm sure that there are books and things like that. This is something that kind of comes by naturally for me. Maybe I'm a little on the obnoxious side, but I share everything. That's like, that's why, that's often why people think that I get so much done is because I literally share everything that I do.

So I may not be getting more done than anybody else, but I just share everything. Yeah. I don't really have any specific advice. Well, I don't know, this may not be totally related, but one podcast that comes to mind is the Soft Skills Engineering. I really love that podcast there. It's hilarious. Just it's it. Entertainment value is good all by itself, but they have some really good advice and often about communication.

All right. So would you mind sharing a link with that in the Discord later on so Juan can find it and the rest of our audience also of course, and to follow up from my side, just talk to people. If you want to know if people like you, you'll probably get a fair answer if you just go down for a one-on-one, but it might be scary. So yeah, if you don't like that, I would understand.

Yeah. Let's take a moment. We are reaching the end of our fireside chat. Just to be sure that we don't go over time, let's take a moment to go through the poll results. So Kent has asked what the percent of time you were spending on the different things of testing and the winner is Hooks? 100% with a 46%. That feels really weird. 100% but 64% sorry. In Dutch numbers, you said it the other way around. I'm sorry. It's always hard for me.

So Kent, is this what you were expecting? I've been giving this poll on Twitter over the course of, though, since Hooks was released every few months, I'll give this poll. And it's just very steadily going in the direction where very few people are not using, primarily, Hooks. And this is why I totally dropped classes from all of my class components from all of my teaching material as soon as Hooks came out. I was like, I'm done teaching that. You could go look at my old stuff if you want to learn about classes. I am 100% Hooks everywhere now. Well, that's good. You got to keep up with the modern stuff.

And you don't want to write something that people are not using anymore. So that's great. I also remember that a few months or maybe it's over a year ago, you asked if you should write TypeScript for your material on Twitter. What was the result on that? What did people like? Yeah. Well, sometimes I do polls just because I'm interested in what people say, not because I'm gonna change what I do. And so, yeah, I kinda do what I want and the people who are cool with that will follow me along. But yeah, so I am definitely doing TypeScript for all of my stuff. I'm in the process of obtaining all of Epic React to do to be in TypeScript 100%. I'll have to re-record all 350 videos for that, which will not be fun. I am gonna make a TypeScript course or series of workshops for people. So if you haven't done TypeScript before, you can go through that. I also already have a script that'll remove all the TypeScript. So if you don't wanna do TypeScript, you can do that too. But I just think that TypeScript, it makes even the learning experiences better because you get auto-complete and it just, that's an enormous benefit as you're learning. So yeah, TypeScript all the way.

All right, great. Another question from Luke. One minute, so be quick. What are your opinions on linting your tests? I lint my tests. There's a linter plugin for testing library that you can take a look at. I think there's actually, yeah. So I would recommend using that for your tests. It helps you write better tests. I also write my tests in TypeScript. It can be kind of annoying sometimes, but you kind of figure out clever ways to, especially like with mock functions and mock modules. But yeah, I recommend typing your tests and linting your tests. Wow, I was not expecting that, to be honest.

Well, since that was our last moment, my memory is slipping. Do you have a speaker room available? Are people able to continue the conversation? I'll be in the Spatial chat for folks to chat with right after this. Awesome. Well, that's it for our little fireside chat, Kent. Thanks a lot for joining. I had a little fun and yeah, unfortunately I can't continue in the Spatial chat, because I'm needed here. But yeah, hope to see you again soon. Yeah, likewise. Thank you so much.