 Okay. So yeah, I'm talking about testing with components with jest. So I'll just give a quick overview. I'm going to go through a bit of assume knowledge first. I'm going to do a bit of background. I'll talk a bit about JavaScript testing ecosystem and we'll get into the meter potatoes of it. So, you know, testing twig and then I have a few final words. So you're just getting started. There's some assume knowledge. I'm going to go through here. So some of the code samples here will have things like model JavaScript features like object destructuring and arrow functions and ECMAScript modules. So yeah, if you're not familiar with those, those things might be a bit, you know, if you're sort of JavaScript skills are a bit a few years behind you might might have a few questions there. But you know, if so seeing out. And then the other thing is that you're familiar with the concept of component driven design. So I'm just going to give a bit of a recap about the front end development workflow at previous next. And we've talked about these things for going back quite a few Drupal South. So the first one was soul guide driven development, which John Albin presented on in Melbourne in I think 2014. Then if following from further from that, this is kind of like the evolution of our front end development. Jack Toronto presented on twig ninja top tactics. And then since then we've had our front end development team, which I think Ricky Jack and Tony drove moving to use post CSS instead of SAS. And then Sam and the same team then moved us over to using roll up to basically Transpile and aggregate our JavaScript. So basically the way we work is front end devs can write all the components and page mockups in a style guide using KSS node, which is something that John presented in that first presentation there. So basically each component gets its own folder for one of the better word and it has basically the CSS and the JavaScript scope to that component. And then we join those together in our style guide using KSS node to create full page mockups and all this happens outside Drupal. So it's sort of rapid prototyping. The JavaScript is scope to each component. And once that's sort of done and signed off on and sometimes that's basically what the client signs off on rather than a fixed Photoshop file because obviously Photoshop doesn't have a concept of responsive design. So from that point then the back end developers integrate that with Drupal. And this is where Jack's session from Auckland about Twitter ninja tactics comes in. And that's about using some of the features of Twig such as embed and extend so that you can actually bring in external Twig files into Drupal so that you can have the bulk of your markup in a style guide that lives outside Drupal. And then your HTML dot Twig templates that are in the Drupal theme but in just Twig files that live in a style guide. And full disclosure the degree to that of which the degree to which that happens on our projects varies per project. We have some projects where there's not a single HTML tag in the Drupal theme and every single HTML tag is in the template and style guide. And then we have some other projects where it's less or so. And there are some advantages to doing that and we'll talk about that a bit later. But of late there have been challenges with the approach of having all of the markup in the style guide because of layout builder. But there are ways around that now too because there's JavaScript implementations of Drupal attributes and we've got our KSS builder now that basically can handle those special regions that layout builder requires. So that's a bit of the background. And then the next thing I want to talk about a bit is React. And I know this is a Drupal Meetup but this story starts with React and yeah basically React is a front end framework that was originally from Facebook. And the basic guts of it if you're not familiar with it is you have a known state so that state can come from outside a component or can be internal to the component. And with that known set of state that yield to fixed set of markup and that state can change and it causes the markup to update. And so this type of model is not that similar to twig in the first render. So with twig have variables, the template plus the logic and you get some known markup. So this is the starting point of the difference being obviously React is in the browser and so it does basically using something called shadow DOM. It does sort of diffing of the DOM as state changes and just makes updates to the DOM as required. But we're stuck in Drupal and where we've got tools that are supposed to which are twig. So with twig you can obviously test this fixed variables plus template plus logic equals markup. You test that with PHP unit, there's no dynamic in that setup. You've got some point, you've got some variables, you've got a template. You might have some logic in the template if some ifs, etc. But you end up with a fixed markup at the end. And yeah you can test that with PHP unit. In fact we've got projects where we use twig in Drupal 7 and we test it with PHP unit. So this is not really anything groundbreaking or fancy. This is what twig is written for, what's used throughout the PHP community. But these sort of tests are fast and robust but don't get you so far because obviously you're going to have some dynamic behaviors. Obviously with, you know, we use twig on the Drupal side to build some markup but then the markup's sent to the browser and that's where JavaScript kicks in and starts to add interactivity and dynamic behaviors. And yeah, so with previous next, all of that front end code, that JavaScript we've written nowadays in vanilla JavaScript. We might use the odd npm package here and there for something like autocomplete or carousel where there's a good library for that and we use ECMAScript modules to include that. And so the roll-up work that Sam, Ricky, Tony, Jack, etc. have done. Basically our build process, we end up with a transpiled JavaScript package that's ready for use in the browser and we put that in our libraries.yaml. So yeah, once we start adding JavaScript functionality, then the ability to test this stuff with PHP unit gets us to a fork in the road. And so returning back to React, this is where we start to get some more envy. So, you know, the testing tools for React and for the dynamic behavior are really solid. Before hooks were a thing. Now, we're talking about React hooks here, not Drupal hooks. You know, Enzyme from Airbnb was kind of the best practice, had a fairly wide adoption, but then hooks were brought in and basically React effectively overnight stopped their main test library Enzyme from being able to render things and so the newcomer out of that was the testing library. So yeah, there's a suite of tools in the testing library, all gone GitHub, React testing library. There's also a view testing library, DOM testing library. So they're basically a suite of best practices for testing JavaScript, particularly functional behavior where you've got browser interactions and the like. And the runner for that is Jest. So Jest is kind of similar to PHP unit in the PHP space. It's a test runner. It has all the assertions that you would expect. It has snapshot testing, which is a pretty cool feature and I'll get to that in detail if time permits. And it also does code coverage. So effectively you can think of it as pretty much the same thing as PHP unit, but for JavaScript, you know, in the most simplified terms. So just a real primitive example here. We've got, you know, this function takes two variables and adds them together. So testing that with Jest would look a bit like this. So we basically use a ECMAScript import to bring in the original function that's on the test and then we just declare our tests and we use the expect, you know, sum of one and two to be three. So nothing too fancy there. So as I mentioned before, when you start to test React components, it gets a little bit more complex. And this is where the testing library modules come in. So looking at a bit more complex example of that, you know, we're looking at a test here for a really simple counter. I don't know if you can see my mouse or not, but I'll try. So yeah, this is counter component here. We're rendering it. That returns an object and we're destructuring that because we want some of the returns out of it. We can fire events like clicking on the a plus button that, you know, let's assume comes out of this counter and then we can do things like query for the counter and, you know, make sure that the content was updated. So it's pretty sweet. It's lighting fast because it's using a browser emulation under the hood rather than an actual browser. And yeah, it's as a developer, it's pretty envious of that when you're working on a React project, you know, and then you come back to Drupal and you have to contrast how we do front-end testing with Drupal. It's, you know, there's a bit of envy there. And, you know, we have tools for front-end testing, we have Nightwatch, we have PHP with Chrome, but these are functional tests and obviously because they're driving our own browsers, they're typically slow and you can't collect code coverage and those kind of things. So I got thinking about this and we're already using twig JavaScript. So there's a JS implementation of twig that we use in KSS node and we have for some time and it's pretty much like for like with Drupal's twig. It's written and maintained by people from the Drupal community. There's implementations if you need them of all of the Drupal filters like check markup, etc. So I sort of thought, well, maybe we could leverage that and have React style testing on twig. Is that a question or is that just background noise? Sorry, I thought I was muted. Oh, it's okay. I'm going to play along. So yeah, this is where twig testing library comes in. So this is NPM library that you use obviously just for development. So it's the same ergonomics as a React testing library but it's full twig. So here's an example test here. We're testing that we can render a particular twig file. We're passing in some variables to go with it. We're getting back from that queries that we can use to interact with the container that's been rendered. So we can, for example, get a button from that, click on the button, find that something else exists. So it's pretty much the same features as React testing library but it's built around testing twig files. So how does that look when you run it? So I've switched to terminal. Is that coming through? Yeah, it is. Yep, thank you. So yeah, if I just run guest and it'll run my tests. So what I've got right here is the test of an accordion. So not a trivial test. Yeah, so what we're testing here basically, I was just going to jump over in the PHP storm. I'm testing a accordion file. So this is just a twig file. We've got a details element. We've got a summary element. I can dump up the font size on that. We've got some more complex things like includes. We've got some if conditions, et cetera. And the test for that, basically, we can render the twig file with some variables. And it even supports namespaces, which is a feature of twig that you may be familiar with. We can query for elements. We can take snapshots and I'll come back to that. We can check that the classes that were expecting the JavaScript to add. Sorry, I should have probably shown the JavaScript. Yeah, so this is the JavaScript that goes with that accordion. So there's like a constructor that does some initialization and then there's some events for focus blur and click. And we can test, for example, that these classes get added in these area. These area attributes get added. So, yeah, it runs, it runs nice and quick. That was three seconds. We can also get some neat things out of it like a coverage. So run the same thing again with co coverage. And it tells me, and this is just a feature of chess that, you know, I haven't written any tests for these lines, which is pretty nice. And, you know, you can do that what you will. One of the things I wanted to point out, though, was this snapshot. Now snapshot testing is a bit of an odd concept. We don't really have anything like it in PHP. There are libraries for it. But if you leave with nothing else out of this presentation, maybe it could be this snapshot testing. So this is like a bare minimum test each render. So, yeah, render some file and expect the container to match snapshot. And what they will do is it'll generate a snapshot file in your code base. So they look a bit like this. And it's basically a, I guess, like a footprint of a fingerprint of what that markup should look like when it's going through that template. And as a bare minimum, if you inadvertently change something in your code and the markup changes, your test will fail. And that's sort of a point for you to pause and look and see, oh, okay, did I did I mean to break it or is that accidental? So for example, if we just go back and let's go back to that. Call your markup and just change the class here inadvertently and run those tests again. It'll fail and say, you know, the snapshot doesn't match. And it shows us here what changed. So it went from according content to according dash content. And if you meant to do that, that's great. And even tells you to run it again with minus you. So you just run just minus you and it'll update the snapshot when you check that back into your repository. So, you know, if that's all you leave with out of this presentation, that's great because then all of a sudden you've, you know, you've got some additional safety nets in there. So there's from other wins that we get out of this. One of them is the coverage we've already seen, but you can also get, you can run these tests in PHP storm and also in like any other IDE. But one of the news parts about it is you can actually debug your JavaScript. So if we wanted to debug something that wasn't working in click, we can just put our debug breakpoint and run our tests in our IDE debugger on. And, you know, we're going to have to jump in between the browser and our IDE. It's a little bit slower. Debugging always is, but we can have a look at everything that's in scope at the point there and, you know, debug something right there on the spot. So the question is going to be, where's the Drupal in this? You know, this is all JavaScript. You know, there's no Drupal so far. And, you know, we're testing trig files in isolation here. There's no Drupal in the mix. So this is all part of your testing pyramid. So this is the testing pyramid. So these are part of this unit's tests laid down the bottom or maybe integration test. But, you know, you can test your JavaScript in isolation without the full stack of Drupal. But, you know, they're fast and they give good coverage, but there's lots of moving parts here. And you obviously still need functional tests to make sure that when everything is plugged in together that, you know, things still work the way they should. And so the best way to maximize your return on this would be to keep your JavaScript written in vanilla. So you don't need jQuery features. It makes it a lot simpler. You're sort of testing a smaller surface area. Keep your components atomic. You know, don't have bleed between one component to another if you can avoid it. And if you can, as I mentioned before, you know, make your HTML.twig files in Drupal just embed the templates from your style guide. And then that way you know that there's not that much variation between the two. If you're duplicating all of your markup back over into Drupal, then obviously one changes and the other doesn't, your tests still pass and you don't know anything about it. So, yeah, that session that I mentioned at the start there, twig ninja tactics from Jack, that goes into good detail on that. Yeah, so summing up. Yeah, that's the URL for the library. And this is early days for this package. So welcome pool requests and anyone getting involved. Yeah, any, any questions? Have you tried to use a storybook for twig components because they look like they're very self contained? We're using cases now that there's a very, which is very similar to storybook. I believe Nick, Nick Fletcher, one of our front end developers has used storybook. I'm not sure if you're using it with twig. But yeah, they're very similar problem space. They're trying to keep that canonical resource of, you know, all of your elements. And there was some really good sessions at RareConf IU, which was in Sydney in February on that front. I, if you have time, I would encourage you to check out the one from Seek. Their style guide is like they basically do their UI prototyping in their style guide. It's got like a little an editor and they, and it's got all the completing for all their existing components. They sort of build out their larger UI using just the components from their, from their style guide. It was amazing. Yeah, what is it comparing with? It says it's like comparing with some standard like when it's doing the test. How do you set that up? Sorry, there's a bit of quite that question. What, what is, how do you test the, when you're testing a UI? How do you set up the, what you're looking for? Like, so, you know, if your software is not compatible. Yeah, script against the UI. Yeah. So under the hood, Jess can be used, configured to use two sort of emulations of browser. And in this case, we, it's using JS DOM, which is a JavaScript implementation of the HTML DOM spec. You know, so the HTML elements and most of the browser DOM implementation, it very deliberately doesn't implement all of it. So things like navigation and the like, you know, which shouldn't be happening in your tests because you want to be testing something in isolation. It will throw errors. I think that's what you're asking. Yeah, that's it. I did HTML. So yeah, if you, yeah, you saw using a DOM to set up. Yeah. So it's using JS DOM under the hood. When you render it, let me just jump back. When you, when you actually like do the render, one of the returns you can get back into the container and that's basically a HTML element, which is, if you look at the HTML element as part of the DOM spec. And yeah, you can like put anything that you can run against HTML element in JavaScript against that. So you can use things like crew selector and the like, and if you like class list and you can, you know, dataset, all those kinds of things. So most of the power of this is just building on top of DOM testing library, which is one of those standard libraries that I mentioned earlier. And yeah, it, it stocks a very exhaustive about how to use the various creating methods. I mean, in this instance, I'm using get by text, which lets me find elements using the text. So I think I'm using it to find the accordion title. But it could vary. It's got a lot of different methods that you can use to basically interact with the DOM. Okay. Okay. Thanks for that. Thank you.