Transcript from the "Jest Config Review" Lesson
>> Kent C. Dodds: Okay, I think that is it for the Jest thing. So let me just go through a couple of take aways. So what we had to do, and just kinda overview of what we had to do to make this work. We had to add the jest as a dependency.
[00:00:17] Here actually let me get my git dif reset soft add backone. There we go, so now I get my lines. So we added just as a dependency, I did any object proxy as a dependency and our new babble plugin. So those are all the dependencies we needed for to support all the stuff that we got.
[00:00:38] We also just added these two scripts to make that work. We added a couple tests, as one does and then we added our configuration. The moduleNameMapper to support css modules and css. If you had graph QL things that you're importing, any loader that you're using with that web pack, that's what this thing's for.
[00:01:01] Our setup ScriptFile to take care of any polyfils that it doesn't come supported with, and yeah, anything that is not supported by default. Collect, we specify where we want our coverage to be collected from and what we want those thresholds to be. And then we also have to update our bulk RC because we do care about tree shaking.
[00:01:26] And we do have dynamic imports and we have to support that as well, that was what we needed to do to configure Jest. Any questions about configuring Jest?
>> Speaker 2: What was the command you typed in to open up that webpage with the coverage?
>> Kent C. Dodds: Good question, so, actually nothing too special.
[00:01:52] The Jest will create this coverage directory, which by the way you should add to your git ignore because it's generated files, who does that? And then there's an lcove-report in here. And this is just the sort of website that it generates for you. And so the open command is just like let me think I think this works on the Windows too.
[00:02:12] And it will just use the default program that I have set for this file type. And so I could also open this up in finder and go double-click on it. But yeah, it will be in coverage, I'll cover for it in next HTML, any other questions?
>> Speaker 3: There's a question on the chat.
>> Kent C. Dodds: Thank you so much.
>> Kent C. Dodds: In a large organization such as PayPal, who's responsible for setting up tooling for testing, coverage, CI, etc.? So it kinda depends, so at PayPal they had testing when I joined up, a couple of tests with Mocha, but not a lot. I cared the most about testing, so it was my job.
[00:02:59] I just said, hey, I want to write tests for this and I want it to not be terrible. So, yeah, so I actually migrated us from Mocha to Ava. And I was like guys, listen, this is gonna be amazing. They were all guys on my team, luckily that changed.
[00:03:16] It's gonna be amazing, and Eva will run all of our tests in parallel. And this was a while ago, Eva was still getting built, ended up being way slower and so many problems. And so everybody was like Kent, you don't know what you're talking about. And then I came to them later and I was like, hey, listen.
[00:03:37] So there's this Jest thing that suddenly just started to be really awesome. Please let me migrate us over to Jest. Come on Ken, last time you did that it was like terrible and I did. And now they all give me standing ovations anytime I come into the office, like, he's the one.
[00:03:54] He brought us Jest, it's not really what it's like, but we're all very, very happy with Jest. So it's kind of my job, in general I just suggest that's it's the engineers job. I feel very strongly that QA has an important role to play, but engineers should be responsible for testing their code.
[00:04:16] So, yeah, engineers are also responsible for setting up the tools.
>> Kent C. Dodds: Okay, cool, there's one other thing that I just kinda wanted to show you that actually in an application or in a project that has multiple, you need to adjust multiple configurations is really useful. So at PayPal we have our front end code and out back end code all in a single repo, and we're testing it all with Jest.
[00:04:48] And Jest has this really, really awesome feature that I'm utilizing in this workshop. So if you look at the Jest config at the root of the project, we've got all of our coverage configuration in that root JEST.config.is. And then we have this projects property here. And that points to the directory where there's another Jest configuration.
[00:05:16] And when you do that, if we run, go back up here. And if I run node_modules/.bin/jest, however you want to run that. And it's gonna pick up my jest configuration, my default and it will run all of these in parallel. And if I do watch mode, they'll all be together in watch mode.
[00:05:38] But each test is running with a different configuration entirely. You can add a display name to your configuration, so that you know which project these are in. But yeah, that is like a very amazing feature. And then it will combine all the coverage, because I don't care to separate the coverage.
[00:05:58] I just really care about the whole coverage overall my whole project. So if I open the coverage/lcov-report in here, then I'm gonna get client side and server side. And if I want to, I could set this and I cover it's threshold to be like so on a client side, it should be this, on the server side, it should be this.
[00:06:17] Whatever you can look in deeper into the covers threshold options, but yeah, this is just an amazing feature. You probably will use it if you're repo isn't just a react app, if you have multiple things in there. For your set-up script actually, just for funzies, we've got several jest configurations in here.
[00:06:39] So this is the one I run, when you run the set-up script. So we get a client server and a whole bunch of other configurations all running at the same time. Jest is so awesome. So anyway, that's Jest.