 Hey there, Polycasters, Rob here. Today on the show, we're gonna be looking at how to test elements that require Ajax to talk to their back-in using Web Component Tester. That made no sense. Let me back up a little. Today on the show, we're gonna be continuing our series on Web Component Tester by looking at how to test elements that require Ajax. Now, if you go check out the documentation for Web Component Tester, you'll see up there at the top, there's a list of libraries that come with Web Component Tester itself. So we've got Mocha, that is our testing framework. We've got Chai, which is our assertion library, and we'll be talking about that in a bit. We've got Async and Lodash. These are libraries, they're just sort of like utilities. They help us do things like manage callbacks and do fancy functional stuff. And lastly, we've got Synon. And Synon is a little library that lets you mock XHR request, create fake servers, do really anything you'd wanna do if you wanted to simulate an actual server. And rather than like create some brand new component or anything like that, I'm just gonna write unit test for a preexisting element. So I'm actually gonna use one of the Polymer Team's elements, IronAjax, and I'm just gonna write test against that. So that way I don't have to come up with like a weird contrived example, because I'm lazy. So what I'm gonna do in my test file is start off by importing IronAjax, and then I'm gonna write a little test fixture for it. So inside this test fixture, I'm calling IronAjax or I've got a little IronAjax tag, I should say. And it's URL is set to response to get with JSON, all right? And then after that, I'm going to create the suite that's gonna hold all of my unit tests. So I'm just gonna call my suite IronAjax just so it's kind of like a nice general thing. And I'm gonna create some global variables in here. These are just gonna keep track of the IronAjax tag, of the requesters we're sending it out, of the Synon server we're gonna set up, nothing too fancy here. After that is created, I'm gonna call a setup function. And this is where I'm gonna go ahead and start to build my Synon server. So I'll call Synon fake server create, that's gonna return an instance of the server. And then I can call this respond with method. And what that's gonna let me do is basically set up routes that I want the fake server to respond to. So what I'm saying here is when there's a get request for the route response to get with JSON, I want it to respond with a status code 200. I want it to send back those response headers that I created up at the top. And lastly, I wanna send back this little JSON payload that says success true. So I've got that squared away. Next thing I'm gonna do is create a little teardown function. And in this teardown function, I'm going to tell the server to restore itself, which basically means like clean up after yourself. You know, if you created global variables, if there's any shared state, anything like that, just get rid of that. So when we run the next test, it'll be a nice clean slate, okay? So I've got that squared away. Now I can write the suite that's actually gonna hold my unit tests. Inside of here, I will call a setup function. I'm going to grab my test fixture and sort it in that Ajax variable that I created. And my first test here is just going to verify that the Iron Ajax request is going out and that I'm getting a response back and that the data in that response looks correct. The test message is gonna be, has seen defaults that love you because it does love you. So my request object is going to call Ajax generate request and then I can just call server.respond. And this is kind of one of the cool parts about working with Synon. Normally you would have to, if this was like a real server, you'd have to wait some amount of time, set up an event listener, do some sort of like async test thing to get that response. Here we can treat it like it's synchronous and that's really nice. It means our tests are gonna be really fast. And after that, I can use expect to inspect the response object that I got back. Now in the last video, I used assert to inspect my objects. This time we're using expect and basically because we're using Chai, we have a few different assertion types that we can use, a few different assertion libraries if you will. I can go check out the documentation for Chai, maybe I should like, clue the link to that or something. Expect just another flavor of assertion, really not too different. What we're doing here is we're first checking that the response is okay and that means that it wasn't an error, it wasn't null, we got something back. We're checking that it's an object, that's what we're expecting to see. And lastly, we're checking that the success property is set to true. This looks okay to me. Let's switch over to the terminal and we're gonna run the WCT command. Things are happening, things are happening. And we get our test back, awesome. All right, everything's green, looking good. I wanna do some more testing though. I wanna test a post request. So I'm gonna create a brand new test fixture and this time I'm again using an IronAgeX element. I'm setting the method to post and the URL is response to post with JSON. Just like we did for the get request, we will set up a route in our Synon fake server. So we're gonna say that we want it to listen for post request on the route, response to post with JSON. And when it hears that, it should send back a 200 same response headers as last time. And this time the object it sends back is gonna say, post request is true. Over here in our test, I'll write a brand new suite for making simple post requests. The first test I'm actually just going to verify that when I set that method to post that that is actually setting the XHR method. So I'm not even calling Synon here. I'm just verifying that under the hood, the element does what it expects. After that, I'm going to go ahead and actually ping the Synon server. I'm going to test that the response is okay. I'm going to test that it is an object and I'm going to test that post success is equal to true. Let's switch over to our terminal. We will run a component tester and we will wait waiting on things to happen. Great. So we've got all of our tests are passing. Everything's green. Now, what if those tests weren't passing though? What if one of them had failed? What if it was just like one browser that failed or something weird like that? What would we do? This is where I'm going to show you a little trick here. When we run the web component tester command, we can actually pass it the dash P flag. And what this is going to do is it's going to leave all the browser windows open. And this is really useful because it means we can open up the console for those different browsers. We can inspect them and if there were errors, they're going to show up there. So here I've got Firefox. I'm going to zoom in. I'm going to open the Firefox dev tools. So I'm going to enhance this and you'll see that I've got my tests listed here. But if there were any errors, they would show up there as well. So pretty, pretty helpful little feature there. All right, that covers testing with Ajax with Synon. There's actually a lot more you can do with Synon, but I've definitely given you enough to get started. There's a lot more that I want to cover with web component tester though. So if there are segments that you are interested in seeing, please leave a comment down below. That way we can try and make some of those episodes happen. Also consider clicking that like button or the subscribe button if you truly love me. And if you have some questions, you can ping us on a social network of your choosing at hashtag askpolymer. As always, thank you so much for watching and I'll see you next time. Turn your phones off. Gotham needs me. I got a head of myself.