 Mocha, QUnit, Jasmine, Chai, ProxyQuire, Synon. See, some people say that we have tooling fatigue in the JavaScript community. I don't know what they're talking about. No, never mind. I really don't. So, let's see. We had QUnit back in 2008. It was pretty popular. Yeah, that's the one. Still, people still use it. That's the one that runs in the browser. Yep. It was popularized, I think, by the jQuery project, ran well in CI. Didn't have amazing support for async testing back then, or headless testing support. Yep. Then we had Jasmine come after that. It looks super similar to Mocha, that one. Yeah. Required you using Karma or Jasmine Node for your test runner. Had a headless testing setup out of the box. Lots of CI support, BDD. Nice. Then you had Mocha, which you wanted to talk about today. So, Mocha is like, it's the main reason I like it. You can run it in Node. You can run it in the window. You can run it in a worker. Which, at the moment, I'm doing a ton of stuff testing across browsers, which helps with Node. A ton of stuff where I'm testing like caches in the window, and then service workers, which are workers. So, having Mocha run in all three things is like super nice. And basically the way it works is you just call describe function, pass in a string, and a callback. String defines the test suite, and then the callback is just the thing that gets called by Mocha. And then you start running your tests. Cool. So, a single test is basically called it. Pass in a string of describing what the single test should do, and then another callback, which is like your actual test. You do certain things, and then you'd use like an assertion library to then basically say, this is the thing that I expect to happen. Make sure that this is it. And Mocha's got like async testing helpers like done, but you don't have to use that. No. So, you can pass in done to your callback, and when you call it, that's basically telling Mocha, hey, I finished the test, move on to the next one. But you can also just execute like synchronous code, and it will just figure it out. Or if you return a promise, it'll figure out what to do based off of that. Sure. Normally what you'll end up seeing is people using it with a thing called CHI, which is an assertion library, which basically CHI has two modes. You either use expect or use should. And the difference is meant to be the kind of testing you do. I don't know enough about that to really comment on it. Generally, I use a thing called should from CHI. And basically what that means is whenever you get a value from a function or something, should like adds a ton of stuff to the prototype. So in the stupid example of two plus two equals four, you do two plus two, you get a value, and then you go value dot should dot equal four. And that's basically the assertion bit. Because if value doesn't equal four, then the whole test will fail, and then Mocha will go, ooh, it doesn't make sense. You're stupid. So Mocha, CHI, Jasmine, it sounds like you need a lot of caffeine to make it in this industry. Yes. I kind of want us to do our own test runner and just call it like triple venti, half-sweet, caramel, macchiato, Dutch AS. You nearly messed that up. I nearly did. But you pulled it off. I did. I did. I feel good. I feel good about that. I want to get the top of Hacker News with that. Be great. Be great. Just the fact you said that statement means you're going to get downvoted heavily. Most likely. But you're assuming anyone actually watches this show. That sounds so true. So frameworks generally use some of the tools that we talked about just now. And some don't. Ember people, I think, still use EmberQ unit for their stuff. Do these just have helpers around? I think it's just helpers around it mostly. The Angular team for Angular 2, I believe they're still using Jasmine and Karma for their stuff. And on Polymer, we're using Mocha and CHI still with Web Component Tester. So on the whole, it's not entirely all crazy. And then there's Cinder's new one, the Ava. Ava. So Ava is like a concurrent. So I think that's the nice thing about Ava is there's a clear selling point there is the fact that it will run multiple tests simultaneously. I was actually going to try that out, but I hit enough problems with service workers that I wanted it to do bit by bit. But I am hoping that I can kind of switch to Ava as soon as it kind of gets browser support as well. It's got a beautiful logo. Ava's also good for when you're working with tests that are particularly IO heavy, it just deals really well with those. Nice. But yeah, we've probably not covered all of the test runners and libraries ever created in the JavaScript community. 23 more have probably been invented while we've been shooting. Just make sure you use one of them.