 So this is a jQuery plug-in unit testing. I call it get around the event loop. You'll tell me if that's a normal good name later. So I'm John K. Paul. I'm this guy who lives in New York, as Adam very graciously said earlier. I'm actually not born, raised there or anything. I just think that's the thing you're supposed to say, because you're from New York. I unit test my JavaScript. I don't know that many people who do it, at least around where I work. But I'm trying to get more people to come into it. So how many of you have unit tested in any language? I'm going to be that guy who asked to raise your hand. OK, how many of you have unit tested in JavaScript? Oh, OK, good. That's I'm completely guessing there's a big light here. 20%, 30%. I also happen to be a guy who uses Reveal.js, the slideshow plug-in. I hope you're not too tired of this particular thing. I also have a beard that me and Andy, the speaker from yesterday, had a good conversation about. We'll talk about it later if you want. OK, so this is my I want to show you my first plug-in. This is the first jQuery plug-in that I wrote that I would actually say that I was proud of. This is something that I put up on GitHub and very gratefully no one forked and never used. But let me show you. So this was just something where you could, I wanted an image cropper that was not like jCrop. We needed something where you could drag this around. And wherever you dragged it to, you got the coordinates. Those coordinates right now I'm just printing. But you send them to the back end. Image magic does its magic. And you get the outcome. So this plug-in, I'm showing you the code here. Don't worry about reading it. You don't actually need to know. This is Sans the boilerplate that would go around it. I thought when I first made this plug-in that I wrote something really nice. It was well-indented. It was pretty. I separated it out into functions and this crazy function thing. And because of this nice slideshow thing, it's even syntax highlighted, and it's beautiful. And I spent a lot of time concerned myself with, because I'm releasing this. I'm putting this on GitHub. That was very special a few years ago. So the reason that this was so, or the problem with this is while this code was very pretty and worked in most cases, this has tons of edge cases. This particular plug-in, I don't know if I can create any of the errors now. But actually, yeah, it was right here. I'm not actually clicking anymore. It just stuck to my mouse. If you move your mouse at a weird angle, all the math that I do in my pretty functions breaks. And I really didn't know that. And it took me a very long time to debug this. I had to put a breakpoint somewhere, or console.log, refresh the page a thousand times, try to figure out what was wrong. And it was a very, very frustrating process. I had to write code, then refresh the browser, then, in my particular case, sadly, had to find the place where the widget was on the site, then click on it to get into the right state and hope that I hit the condition where an error happened, and then debug that error. This is a very frustrating process. I'm sure we've all done it. We've all gotten used to it. But there is a better way, and that's what I'm gonna talk to you about now. At least for 80% of you, maybe some of this is new. If normally it's a much smaller group site, I can say, raise your hand and ask a question. I would say yell at me, but I don't think that's gonna work either. Definitely keep your questions, we'll talk about them after. So, this is also my last meme. So, apologize for the rest of it, it's gonna be really technical, no more pictures. So unit testing is the answer to this particular problem. Once you start unit testing your plugin code, or your code in general, you don't always need to manually test in the browser. You don't necessarily need to always be console debugging because what I'll eventually show you gets rid of a lot of that necessity. You can very quickly change the code and then see if it works, because unit testing, the whole idea of unit testing is to create code that tests your code for you. Rather than you console.logging something and then checking with your eye to see that it is correct, a unit test checks that completely in code so you can run it very quickly. It's also nice because you can test your plugin completely in isolation, so you don't have to actually put this into an app or even necessarily an HTML page that has any complexity. What I'm gonna show you is a way to write unit test plugins very, very separate from necessarily all of the HTML that you would traditionally have when you're deploying your plugin. Okay, so I think coming up soon it's gonna get crazy, so bear with me. So I don't know how many of you have tried to, how many of you who have not, do not unit test regularly, have tried to read blog posts and learn about unit testing and try to see a lot of examples out there. Okay, so this is what a lot of the examples are like. It's very straightforward stuff. So this is an example of a unit test that I wanna make sure that this particular function sums and then squares some numbers. And what I can do right now is I'm gonna run this test and it says on the side very nicely that all of these things failed because all of these things are not true. If you see my function actually doesn't return anything. There's no return. So what I can do here very easily is live coding is always dangerous, so let's see what happens. Okay, so here is the simplest unit test, the simplest piece of code. This is the idea behind unit testing. I just wrote some code to prove to myself that my function does what I expected to do. And then I wrote the function itself and said then the test passed and it said yeah, your expectations are correct. What you expect this function to do actually happens. What's nice about this is there's two big nice things about this, I'm pitching you on unit testing now, I'll get back to that everything else later. One good nice thing is someone else comes to this later and accidentally or without knowledge knowing, because I have a very obvious function name here, assuming this function name is a little more cryptic, someone comes in here and changes this to three. Eventually when you run your test, things will break and they will know that something that they just did caused a problem. Also another really good thing is I wrote this really verbosely and no one really should write code like indentation aside, I can't actually hit tab in these things. I didn't write the code to fix that. Someone can figure that out later. So what you can easily do is change this to, and now my code still passes. I know everything is still correct and I was able to refactor my code to make it look nicer. It's a lot easier for me to do that when I have the confidence that I'm not gonna make a mistake because, or rather, I can make a mistake, but that's okay because my mistake will be caught. Okay, so this particular part of unit testing is very, for very straightforward and very easy because it's just function does this particular thing and I know exactly what it's going to do. The next thing of unit testing that I'm gonna show you is also fairly easy when you have a function that doesn't actually need to do much, it doesn't need to call other functions so you don't have to fake out a lot of things. This particular function, all it does is right here, I'm gonna write, return. And here I have my passing tests. All this particular function is doing is checking the data that is on the something that is passed into that function. This is also really easy to test. Not particularly something you would normally do in a jQuery plugin, but that's where the complex part happens. So another thing that I see sometimes and I'm just giving you this that I want you to avoid it, so a lot of people test their libraries and this is, it's just a code to maintain that we don't need to. jQuery itself has something like 6,000 unit tests, I don't remember the exact number, but we don't have to worry about this. This will work. What I'm doing here is writing some code that creates a div and then adds a class to it and then makes sure that jQuery is correct and really adds that class and then adds it to the DOM and then makes sure that it really gets added to the DOM. Realistically, we don't have to worry about this. At least some big part of what you would think about testing can go away because you don't need to worry about all of what jQuery does. It's already taken care of for you. So what you care about, what we need to worry about in plugin unit testing is what do we need to do? We need to make sure that when events happen, we actually control what code does when those events happen. So for example here, it's funny, the previous speaker had an accordion example and I also have an accordion example, but we did not coordinate on this. So here I have a piece of code that in jQuery selects all the accordions and then every time you click on it, shows ULs underneath it. And this is something that's really hard to test by itself because how do you know? You actually have to have an accordion div and ULs and you don't know how to verify this. For example, if I had equals here somewhere, equal. I wouldn't actually know what to put there. It's not obvious how to make this code testable. The same is true for the next one. I add this very large function to the list of handlers that should happen when the window scrolls. It's not necessarily a good idea, this is just the example here. When the window scrolls, all of this happens, but how do I verify any of this? Do I actually need to have a window? Do I actually need to use the DOM events? I'll talk about it a little later to actually scroll the window. That's kind of really complicated. What is the best way to avoid this? Where did they get around this? The short answer of how would you test this is don't write code like this. Ideally, you wouldn't be writing code that completely couples everything where you do too much in one place. Select your elements and at the same place you add all of these handlers so there's no place for you to stick in your testing code and say this is what I want to make sure that this happens at this place. So plugins need organization, in the previous talk also, they set this up completely on purpose, which is a good thing. Plugins need organization so that we can maintain them definitely and in this case, so that we can test them more effectively. So there are patterns, there are best practices as mentioned earlier. You can Google for a jQuery basic plugin pattern, Adios money has a large GitHub repository. That's the one that I'll be using here. Hopefully I'll show you through this code a lot of different ways that you can use these patterns to help you write code that you can then easily test. Okay, so now trust me, I'm gonna show you some code. So this is basically a plugin pattern directly taken from that GitHub repository and modified to do a few things. Can everyone really hard to see? Let me just do this. I think that should be obvious, okay. So this code, what I want to do is it basically sets up a very simple plugin, this plugin when you create the plugin on a particular element, it looks up all of the ULs underneath it and then when you click on them, it shows them this most simple non-functional really accordion. And what I want to do is write a test, something like this. So what this, I want to say when I create this element, I want to create an element, a fake element that doesn't actually need to be in a page. I want to use the plugin on that element. Then I want to take that plugin instance. So what I have here, this particular plugin boilerplate, what it does is when you create an instance of a plugin, it actually just sticks it on the data object so that you can look it up later. So that's the second to last line here. You don't necessarily have to worry about that. So what happened, what I want to show here is once I activate the accordion plugin on my element, and then I want to override a function that will set this flag clicked to true for when it was originally false. So what this code is doing is verifying specifically that when the click happens, this particular function handle accordion click is called. Now how it does that is using jQuery's trigger function. So every jQuery object has a way to trigger events on it programmatically. So rather than a mouse actually having to click on an element that is in the page, you can use the trigger method to make jQuery behave as if something actually clicked. So what I'm doing here is setting everything up and then actually on the second to last line, clicking it, letting the browser click it without actually having to fire the native browser event, and then making sure that this function was called. So this is fairly straightforward. I have to have this global to that function of our variable called clicked. So there's a library called Sinon.js that makes things like this a lot easier. So with Sinon, they actually have something called a spy. Spy is a function that you can use, or it's an object, you create an instance of a spy and all it does is know that it's been called. So rather than having to do that fancy, having the variable that gets set underneath, we can use one of the Sinon spies that has a called property that will be set to true if that function actually gets called. So these are two fairly, this particular one is these are two fairly straightforward tests. I create a plugin, I create an object that plugin is instantiated on, then I try to click or something, I'd actually use an event and then make sure that what I expect to happen when the event happens, it actually does happen, in this case, making sure the handle according click is called. So the pattern here that we need to learn is normally, so traditionally this could be written, this particular init function, when I actually add the click handler, this could be written very differently, this could be written in a way where I, for example, do this. So this could be written in a way where I do not actually put handle according click into a separate function. I could do that directly here, I could type here. So if I did this, I would have nowhere for my testing code to inject its fake function to make sure that that was called. So a big part about how to unit test plugins is to make sure that you separate everything out into ways that you can override. It's called traditionally in the jargon of unit testing, this is called a seam. We need to make as many seams as possible where we can put our fake implementations, in this particular case, I faked out handle according click because that's where I know, if I can verify that that's been called, at least I know that half of things is covered. So back to what this was normally. So now the test that I just showed you, it verifies for sure that when this, when the element that this plugin is created on is instantiated on, when that element is clicked, handle according click is called. So I've covered half the goal because I wanna make sure that the click method is called and then I wanna make sure that if that click method is called that in this particular case, all of those ULs are hidden. So let me show you the next test. Okay, so here I'm using these document.app, I mean the create elements here rather than the jQuery dom builder, just because this syntax highlighter breaks a little bit with HTML. So what I'm doing here is creating a UL and the correct elements, putting them together correctly, and then I'm actually calling that the function handle according click directly and I'm making sure that the CSS display is blocked. I'm making sure that it's been shown. This is a way you can, once you've separated your plugin code out, where you can easily test things separately, then this is fairly straightforward, other than most of this code is building the DOM. And what, so using jQuery's dom builder, which is the jQuery function itself can actually take HTML as a string. In 1.8 this is changing to be a little different, but you can read that blog post. Also, you could also use fixtures, which are blocks of HTML that are in your HTML page at the time that this test runs. This particular, I mean inside this slideshow I'm actually using QUnit. There are many, there are other frameworks as well and QUnit has a traditional QUnit fixtures div where you can put whatever HTML you want to use in your particular tests. So I'm gonna move on to the next plugin that I wanna show you how to build. So this is a fairly common requirement nowadays. The businesses want, or designers want this, oh, this is, of course this demo is not working at the worst possible moment. Well, so normally that would stick to the top. I'm assuming that I'm not on the internet or something and the jQuery on CDN is broken. But I wanna build something where when I scroll the scroll bar down and this particular green div hits the top that I wanted to stick there and then not keep scrolling with the page. So somewhere I have some code like this. Let me zoom in. And what this code is doing is when the window scrolls it checks to see if the element is outside of the viewport and then if it is outside of the viewport it calls some function. This is that pattern that I was showing you earlier, at least that practice where rather than putting all of your code in line, call out to functions that you can eventually override and then in your unit tests verify that are called. I'm not showing in this particular example but you can actually verify that things were called with particular arguments. You can verify that when things are called that they return particular arguments there's the sign on JS library has a large amount of different types of spies and there are other different things that you can use. So what this code is doing, sorry, I told you what this code is doing. I have this element outside viewport function that's a nice separated function thing so it looks really nice and maintainable. So I want to have a test like this. So this is where I create an element, I add my plugin to it and then I get the particular plugin from my data. It just happens to be the pattern that I'm using and then I make sure that when the window actually scrolls by creating this, this is a custom jQuery event. You can create an event using the jQuery event constructor and you can have that event be whatever you want. You could create a click here. The reason that I'm triggering with an actual object rather than a string, I could click here, I could just have the word scroll. This would trigger scroll on window but I'm actually creating an event because I want to make sure that even though there's no actual window necessarily there's not necessarily a browser, there's not necessarily a page or a scroll bar, I need to make sure that when jQuery says what is the scroll top of this window, I need to make sure that it says in this particular example 101 because I want to pretend that the window has scrolled down by 101 pixels. So that's why I create a jQuery event that I add to that, I specify the target of that event as an element that happens to have scroll top as 101 and then I trigger that event on the window. This is, it's a little bit a roundabout way but this is the way that you can write a unit test that correctly gives the right value. The biggest part of unit test is how to figure out ways to give the right values to your actual production code. So in this case, so when I run this, yeah, so I can run this and it will actually show you what happens. Let me see, so now I'm gonna scroll this to, so anyway, I know something particularly is not working but this I think happens every once in a while. So I wanna show you, so this test, this is how you would write this test in order to verify that when something scrolls something happens but I wanna show you how to find out how to specify where your element is on the page. So the element that I showed you here this green element right here, this green element might or might not or because it's a fake element it might be completely at the top of the page it might not necessarily be on a page at all. So how would you find out how to specify in your code where that element should be? That's this element that's created right here. The element that will eventually be stuck to the top of the page. So in order to find that out, basically my code in here is calling offset. This.element.offset. So I need to somehow make jQuery for that offset return back the values that I want. I want, I need to make sure that that if I want to scroll to 100 pixels and my element is at 110 pixels that nothing happens because it hasn't been scrolled past. If I want to make sure that it's been, if it's at 100 pixels and I scroll to 101 then that's okay. I don't know if that logic made sense but I'll show you what I'm talking about. So basically I need to override what offset returns but this is, this is in jQuery. How do you, how do you do that? And it's taken a while for me to get used to this or comfortable with this but you can actually look into the jQuery code and often it's crazy and you don't understand it but sometimes you work at it and you read it a little bit and it's okay and I'm gonna show you in this particular case it's a little bit daunting but we can figure out where to write our code, how to write our code to let, to inject into jQuery what it needs to be able to control what it returns in this particular case, controlling what offset returns. So, so this is the code for offset. It is long and a little complicated but let me zoom in for you. Okay, so there are not that many returns here. So if there are not that many returns we can just go through them and figure out where it is that we can write, how we can write our code so that we can control what offset returns. Okay, so the first one is if options. We're not passing anything into this so it's obviously not this return. The next one is return null. We don't want it to return null because maybe it's not gonna return null because it doesn't normally return null. Next one is return this body offset. Why would it return the body offset? If the element that it's on is the body which is not the case. So it's definitely not that one. Okay, skip all of this, don't understand it, don't need to worry about it yet. Skip all of this, return, okay. Return box. So if box is there, return box.top and box.left. Okay, so that means that I kind of know what they're returning. I don't know why they're doing this but I'm reading the code and I'm seeing that this is happening. So let me go up a little bit. Where is box defined? So box is the elements get bounding client rect. Okay, I don't know what that means. I have no idea what that means. I could look up at MDN but I don't know what that means. But I know that if I have an element and that element has a function called get bounding client rect on it, I can override that function and do whatever I want. So let's go back. So if I want to specify, yes, sorry, one second. So what I can do here is override the element specifically, override the function that I know jQuery is calling because I read it. I don't know why it's calling that but I know that now that I can stick in here some data and say that there we go. Okay, so my test just failed because I specified that my element is at 100 pixels yet but I have only scrolled to 99, okay? But let me change this to 101. Pass, my test just passed because I told, I've override the function that jQuery calls internally to say that the new element that I just created, sorry, we'll zoom in, the new element that I just created is at 100 pixels from the top and 100 pixels from the left and the window itself has scrolled 101 pixels. So that means that, wait, this code is wrong. It should have actually, the element scrolled off should not have been called. So my test passes. Other way around. So this is how you can read jQuery source not necessarily understand what it's doing or why it's doing what it's doing but you actually can find out. If you Google for get bounding client rect there is information out there. I'm sure that there's other documentation on MDN that'll make this make sense but you don't necessarily need to know that when you're concerned with unit testing your plugins. All you need to do is understand that there are places in jQuery and in your code that you can override certain properties to return what you want so that you can successfully test your plugins. So that you can put everything in the right state without actually needing a browser or actually needing, without actually needing HTML and an entire page backing everything up. Okay, so I'm gonna do a quick explanation of AJAX tests. I've, that's, well, I'll figure out about time. I've started a little early so let's see what happens. So I have a very quick example of a plugin here that doesn't do much except it makes an AJAX request to this URL data and then when it returns it sets the text of the element that the plugin was graded on with the message property of the JSON data that was sent back. So normally an AJAX test is kind of complicated to write by itself even if you have a backend because these are asynchronous. So rather than being able to test like completely insurial you have to have eventually in your test something that would pause and say let's wait a little bit of time, set time out for some time in the future when that AJAX call returns you have to figure, you have to figure everything out then. But Sinon has this great feature called use fake, use fake XML HTTP request. And what this does, even though it is complicated to say, is it gives you back an XHR object and it overwrites the native XHR to use something that is completely synchronous and you can control programmatically. So, whoa, that was very loud. So basically using this Sinon fake XML HTTP request you can create these XML HTTP request objects that in this particular code I'm just storing in some variable. And then if you see on this line I'm creating that AJAX plugin. That AJAX plugin should go out, it should make this AJAX call and then return and populate the data correctly in my element. But what I can do here, this is the really nice part in my unit test. I can respond to that request in my JavaScript. I don't have a backend here. I don't necessarily even need to have a network connection or anything like that. I'm saying this fake XHR that's been created that's requested for data, respond with a 200, respond with these headers in this particular data. In this case I'm sending back the message, and then I can make sure that afterward the text in this element contains the text that I specified from my, the fake response from the server. So we could actually create actual integration tests which is the integration tests are tests that test multiple components. So unit tests test a single class or module or plugin in this case or anything. We could create real events. There is a way to do that. It feels a little more honest because here we're using jQuery's trigger and we're making some, making the assumption that triggering is the same thing. It's not exactly the same thing as using a native event that can actually click on something. You could use, there's a method in, on the document called document.createEvent. When you can create a mouse event in this case then you can initialize that mouse event and then you can trigger that mouse event on an element. You can, eventually I'll give you the links to this. But the amount of frustration that comes from this is almost exactly the same as the amount of frustration that comes from not even unit testing your code at all and having to debug forever. Because the, one of the, a knit mouse event, I think takes 14 different parameters and half of them are Boolean and I have no memory of what they all do and I have very often attempted and gotten all of them very, very wrong. So realistically there, it's not something that I would use and want to be able to, or not something that I think I would be able to successfully use regularly. Also I actually made a JS perf to compare using real browser events with these jQuery triggered events and realistically the difference is not that much at all. So basically in summary we talked about how to utilize event, jQuery's event objects and triggering events programmatically through your code and using that able to make sure and verify that what you expect to happen actually did happen. Then so write your plugins with seams, with methods that you can override, that you can say, oh my spy will go here and I'll make sure that that's called and I'll make sure that that's called with a particular piece of data or something like that. You, there was a lot of utility libraries. I have some resources. Sign on JS is the one that I use most regularly. There's also jQuery mock jacks which is a mocking library that has the same interface as jQuery's Ajax itself. Also read the source, some of it's crazy and you don't have to understand but a lot of good places where you can put your mock data comes from there. So these are the resources. Okay, thank you so much for listening. Do you have any questions? These are all of my information. I'm on IRC all day and there's a link to the presentation. I just wondered, have you found it more helpful to use trigger versus trigger handler in your testing meaning? Have you ever run into a case where an actual note event was actually fired during any of your mocking? No, I have not used that at all. Never used trigger handler? No, I've used trigger handler. I've never seen, for testing I don't believe so. Okay. Okay. All right, I got a question because we were running out a lot of tests about this integration as we're using Qnet. So one of the pain point is that how do you, let's say, how do you deal with the asynchronous test? Like situations? Good question. Things like, okay, what do you present over there? I see that there's pretty much almost instant because there's nothing really involved about like because let's say you had a Ajax but it's a mock one so it returns immediately. So what's your strategy in terms of dealing with things? I'll explain. So this is kind of sound kind of cheating because Sinon actually has a library. I can show you, I think. Okay, so Sinon has another component like fake XML HTTP request where it actually overrides set timeout and set interval. So in the exact same fashion as you can fake out requests that come back from your server, you can actually tick the clock. So you can say, you can write fake set timeout or set timeout is overriding. So you can say global clock dot tick 100 seconds, 100 milliseconds. And when that happens, it actually behaves correctly. Everything that was set timeout, set for 100 milliseconds will fire at that time. So you can set it up to the clock to tick at 99, make sure that everything is as expected, then tick pass to 101 and make sure that everything is expected. That that library mocks everything out for you. I think that, sorry, I didn't hear the whole question but I think that that addressed. Okay, I think we use a similar approach like that. Like say we deliberately wait a few moments just to say, hey, supposedly the Ajax comes back. Supposedly the browser has done its own rendering that we run through like plugins and then we need to make some time just to kind of gauge it. Sorry, can you speak up? Okay, have you thought about using some sort of callback patterns in terms of dealing with like, you wanna make sure some DOM element or some images fully loaded after you did some requests. So how do you measure that? Okay, something is already there and then you can move on to the next step. So if an image is, so this is a unit test. So in a unit test, I would try to have as few dependencies as possible outside of that. So I would try to trigger that event programmatically and say that image is loaded now, what happens? And then maybe in another case in another test, say, oh, that image failed loading, what should happen, does that happen? Right, exactly. I think the particular thing we're asking is about integration tests. So I think this is rarely happening in unit tests. Right, so with integration tests, in that particular case, I have not done significant work with attempting to write integration tests for issues like that, so to be honest, I don't know. But I guess I would try not to have to worry about tests like that, where I actually depend on an image being loaded from the back end. Potentially if this is of extreme business importance, you could, there is other tools that would be more appropriate, like Selenium, Selenium a web driver, there are functional testing tools that will let you actually use an actual browser and have it, for example, set up something where an image takes two seconds to load, actually physically click with a mouse that's moving and verify that your, because your back end took two seconds, X happens, if it takes five seconds, Y should happen. Something like that would be more appropriate for a different testing methodology. But I would try to avoid that, to be honest with you, because it's a lot of overhead that you don't necessarily need to spend time on. It depends. How do you know how much testing is appropriate? I mean, we've got this big, ugly application that, I mean, I look at jQuery 6000 tests and I think how many years it would take me to write all that stuff. How much do you need to do? Well, I'm sure that those tests came over the course of a billion bug reports. So I don't know if that's necessarily that's the right comparison. It depends on what you're talking about. So I think that business logic, so this is kind of separate from plugins. So in terms of plugins, you should be unit testing as much as makes things, definitely makes things easy for you and also makes sure that what your user expects to happen happens. Not necessarily all of your internal logic to do that, but in my example, I wanna make sure that when I click the accordion, the accordion shows, I think that's a very common thing. In general, what to unit test is a much larger, or what to test is a much larger problem. The example of integration tests, in my opinion, make sure that you can pay and then really make sure you can pay and then make sure you can pay and then don't worry about anything else. In terms of unit testing, it is, there are coverage tools, there are unit tests, JavaScript has JS coverage and you can make sure that each line of code is covered. That's not necessarily that valuable, it depends on how they are covered. You could write very inane tests and just claim that you have very high percentage of coverage. I guess in general, that's a complicated question. Test your business logic, test what is important to your company and then test to make sure that you're implementing something the same. I would love to talk to you more about that afterwards. I think it's a long question and my time is officially over. There's a tool called SYN, S-Y-N that I think wraps around document.create-event and it makes it much easier to create synthetic events for testing and it might give you truer results than trigger. Sorry, what was the name of it? SYN, S-Y-N. Okay, so SYN, I did not know about that one. There's also jQuery, for jQuery UI has jQuery, the simulate plugin which maps, I think, directly to trigger. So you can simulate a click event and you can simulate a key down event. In the same way, it calls into document.create-event under the hood. You don't necessarily have to worry about all of the parameters that I mentioned earlier. There are other tools in order to do that but the problem there, it's a little confusing to know how to use it correctly because while you can create those actual events, you can no longer write code that is synchronous because when an actual event happens, the handler isn't triggered in the same execution thread of JavaScript. That click is added to the event loop and then eventually the next tick of the event loop that is picked up and that code is written. So your test will be written very differently if you write that kind of test. Anything else? Oh, there's one over there, oh, Cory. Oh, okay. This is gonna be interesting. It's not like you're my planter. So I was just curious if you had any good solutions for dealing with testing in particular focus. It's been the biggest pain event to try to get working and simulate for UI. We've had a lot of problems in dealing with all the browser asynchronicity around focus. There's just a lot of problems with it. I didn't know if you had a good solution. So no, I mean in terms of actual browser events, I have not tried to be honest. I think as I try my best, or I always honestly write tests, at least when I'm using jQuery, where jQuery triggers those events themselves rather than having the browser trigger them. Other than using the normal asynch testing tools, I don't know of any other way to fake that out. Maybe I will look into it though. I will get back to you. Sure, we'll talk after. Okay, thank you so much. Definitely ask me questions if you have them later. I would love to talk to you.