 Hi everyone, welcome. My name is CJ Kilbone. And I'm Jonas Niklas. And we're from a Rails Consultancy in Sweden called Elabs. And we're going to be talking about the front end testing frontier. Now I assume the reason that all of you are here is that you've already seen Glenn Vanderberg's talk, which is going on in the other room. Because if you haven't seen that, I highly recommend that instead. So I won't be offended if you leave. Given that you're here, I expect that you want to hear about testing front end code, testing JavaScript code. I want to start by asking you, how many of you here test your Ruby code? That's pretty much everyone, right? We love testing. The Ruby community is so gung-ho about testing. There's a lot of, in my mind, positive peer pressure about testing in the Ruby community. It's unlike any other community that I've ever seen. And that's great. But how many of you test your JavaScript code? A few people, but significantly less, right? And of those few people, I think I saw maybe five max ten hands. How many of you find it frustrating? Yeah, that's pretty much all of you. So we love testing in the Ruby community, but only our Ruby code, really. JavaScript code, not so much. So why is that? We think that one big part is that JavaScript testing is neglected in many ways. The reason that I really got into testing when I started using Rails was that it gave me so much for free, really. As soon as I generated a model or a controller or, God forbid, a scaffold, it just put a lot of tests there for me and I just had to fill in the blanks. It was a really, really easy, clear path forward. Not easy necessarily, but it was a clear path forward. I knew what I had to do. I knew where I had to write my tests. And just running rake would take care of the rest for me. With JavaScript testing, there's nothing like that, really. We're completely left on our own. We add some JavaScript functionality to our application. And where do we go next, right? There's no clear path forward. It's also neglected in many ways when it comes to the other things, like the things that go around the ecosystem in terms of tutorials, documentation in general. It's way less than what we have for our normal Ruby testing. So again, not including Rails. This is probably, for me, was the biggest hurdle to get over or the biggest win when it came to Ruby testing. But with JavaScript testing, there's nothing like that. Another piece that plays into this, I think, is that in many ways we don't consider JavaScript real code. A real code is the Ruby code that we have in our models and controllers. But the JavaScript code is just something we sort of sprinkle in to make things a bit nicer. Maybe it's some Ajax to help out with the flow of the application. Maybe it's just toggling an element so that it's only displayed when it needs to. It's not really a real code. It's just something that's a pretty separate application of it. And of course, all of this leads to the conception that JavaScript testing is hard. It's hard to get started. It's hard to get it working. It's hard to maintain. So difficult to set up is probably the biggest part for me, at least. It was really hard to find out where to start. And hard to maintain, JavaScript lives on the client side, usually. So it has all the problems that we have with view tests in general, that views usually can be quite brittle. Just changing the text on the button can break our entire test suite. And stuff like that really puts a barrier in front of us and makes us reluctant to get started with really testing our JavaScript code, I think. And again, there are no established best practices. With Ruby code or with Rails testing, there are really, there are established best practices. DHH has run the other week here, maybe through a wrench into things. But we have test units, we have RSpec, and they're both great. So you can pick either one and you're golden. With JavaScript testing, there's not really one established best practice. There's a myriad of different frameworks, different libraries that all have their strengths and weaknesses. And it's really hard to choose, unless you maybe have help from someone who's done it before and can help you with that choice. So our goal with this talk is to show you that it doesn't have to be hard. We're here to show you that there is a fairly simple way to really get started with JavaScript and to go beyond that as well. But why do we care? If it's just a bunch of tiny bits sprinkled here and there to make our application pretty, is it really that important to invest a lot of time learning, maybe, or a lot of time at least writing the tests, isn't it enough to just load up the browser and click around a bit and see that things work the way we expect? Well, with today's applications, we're writing web applications that really blur the line between web and desktop applications. As our user interfaces become more and more rich, more and more desktop-like, we move a lot of our logic into the client side. And that logic, of course, needs to be tested or we would have tested it if it was on the backend. So we really need to test it on the just moving it to the front and doesn't change that really. So we need to be careful about that. Another big benefit and fairly easy benefit is if we have good tests, we know when we break stuff. We know when we think we're just going to make a little change somewhere and our tests show us that, whoops, this actually broke something in the part that you weren't expecting. And this is something you get for free, basically, with writing tests. It's a very, very important benefit, I think, but probably not the most important. For us, when we're writing an application, we know that it's going to be around for a long time, probably. And as we're working with different clients, we know that we're probably going to be away from an application for a long time and then come back to it maybe six months, a year later. And we want to be able to dive right in and be comfortable in making changes to the application. Or we're turning it over to a client that has to maintain it for a long period of time, training new developers in it, et cetera. And the tests really help with that as well, of course. There's also the issue of refactoring. As all of you know, writing tests in your Ruby code, the most important part of red, green refactor is the refactor bit, right? It's the refactoring that leads us to create really, really good code. And this, of course, helps with the sustainability as well. So by having the confidence in our code that the tests give us, we can refactor mercilessly and know that we're still green. So all of this is about better design, really, which has always been the point of testing code. Writing code that's hard to test is a code smell. So by using tests, you're making sure that your code can be tested and that leads to better design. It leads you to create code that has good isolation, that's not coupled to a lot of different things, and it really, really improves the design of your code. And with JavaScript, this is especially important because if you've been writing an application with JavaScript for any period of time, you know that you usually end up with a huge mess of spaghetti code, right? You're just throwing functions into the application .js file and, you know, after five minutes it's a mess. So by having our tests force us to have a nice design, even for our JavaScript code, by forcing us to isolate pieces in a good way, it's much, much easier to develop that application or maintain that. So what it comes down to is that we're testing our JavaScript code for the exact same reasons that we're testing our Ruby code. It's in no way shape or form different, really. It's all about having confidence in our code and better design. But how do we do it? What level should we test it at? We're going to talk about two different levels, really, and that's unit tests versus integration tests. And that'll cover most of it. Now with unit testing, we're trying to test widgets or components, usually. We're trying to find any isolated logic that doesn't rely on too many different pieces of your code. We're testing pieces that doesn't necessarily need to use rails. If we're testing something that relies on the back end a lot, there's going to be a lot of mocking, et cetera. So unit testing is perfect for the pieces of your application that's very standalone or the JavaScript pieces that is very standalone. Now integration testing, on the other hand, has a lot of other benefits. It's really easy with integration testing to test those pieces of glue code that can be quite hard to test effectively with unit testing. So that's especially true for AJAX. Unit testing AJAX usually leads a lot of frustration. There's a lot of mocking that you need to do. But with integration testing, it's a piece of cake because you don't really see the AJAX. It just happens in the background. We're just testing the behavior of the application instead of the implementation. Another good candidate for integration testing is when we have a very complicated DOM. If we have a page where we pull in a bunch of information from different parts of the application, unit testing those parts might be very, very complicated, needing a lot of setup, a lot of complicated fixtures, maybe templates to create that complicated DOM. But with integration testing, we are testing the actual application as it is, and there's no need for the complicated setup there. So that was a bit of an intro to the frustrations of JavaScript testing, why it's hard, the different levels that we're going to talk about, and I'm going to turn it over to Jonas to talk about how we can actually do this. All right. So let's kick it off with integration testing. Let's talk a bit about how integration testing has been done in the past and how it's being done now. We've had a number of solutions in the Ruby community over the years, and it all started when DHH introduced Rails integration tests. And that was sort of, integration tests had been done before that, obviously, but it was sort of a fringe thing. And when DHH, for the first time, integrated that into Rails, into the framework itself, for the first time, people were actually starting to write these tests for real. And these Rails integration tests, if you've used them, you know that they're written from an HTTP perspective. What this means, basically, is that we're talking about how HTTP interacts with your application. So you're issuing, get requests to your application, you're posting data, you're posting to a specific URL, some parameters, and so on and so forth. This is one major flaw, and that's we're not really testing what the user does with your application. So if we're talking about posting into a particular URL, for example, with these certain parameters, how would the user get there? The user would have filled out a form and posted that form to that particular URL. But Rails integration tests don't really allow you to check in any kind of effective way if that form is actually on the page, if it even has the right names on the input fields, or for that matter, if the labels on the field are even correct. So you don't know if your user can actually see that form, you don't know if filling out that form even posts to the right action, and you don't know if the user can see what fields even to fill in. So Brian Helmkamp, he wrote this library called WebRat, and he wrote this library from the user's perspective. So he tried to sort of capture how does a user work with your web application. A user would go to your site, he would fill in an address in his browser, he would press enter, he would come to your site, he would fill in a form, he would click a couple of links, click a button, he would check for some content on the page and so on and so forth. This library also had a kind of flaw and that was that its support for JavaScript was really limited. It did eventually come with a built in Selenium mode which allowed you to sort of run JavaScript, but it was pretty unstable and it didn't really share the same API. So it was sort of tricky to switch between the two. You really had to make a choice in the beginning of the project over which to use. And this is probably the sort of oldest solution that's still in use for integration tests. Selenium was released in 2004 by ThoughtWorks and I guess most of you know this, it's pretty much a remote control for a browser. So it opens up a real browser, Firefox, Chrome, IE, whatever, and it issues commands to that browser and then in turn clicks, links, interacts with your application and so on and so forth. It really does allow you to test the full stack. It does CSS, it does JavaScript, it does HTML, it does HTTP in exactly the same way that a real browser does because it is a real browser. But for a lot of tests, this does introduce a lot of unnecessary overhead. Maybe you're testing a simple part of your application. Maybe that part of your application doesn't need JavaScript, maybe it doesn't need CSS. Selenium kind of forces you to use those anyway. So you're running a huge overhead for testing a really simple thing and that leads to really slow tests. And slow tests are hard to maintain. And what a lot of the early solutions using Selenium had as a problem was that they were pretty tricky to set up. So if you wanted to get started with using Selenium in your application, you had to install a lot of crazy stuff and you had to put a lot of setup into your application and usually it just took a really long time to get going. So to summarize this whole experience, it's not that fun. And we sat down with a lot of beer and tried to come up with some solutions to these problems. Not sure if the beer helped. I do claim that it did. So what we really wanted to get was an easy setup. A setup that's as simple as possible. We really wanted that same experience that Rails gave you with the integration tests and that WebRAT gave you with the user-facing tests. But we wanted this for full stack testing as well. We wanted to have multiple ways of running tests. We didn't want the overhead of slow executing Selenium tests for everything. We wanted to be able to say that this particular test is simple and it only needs to run your Ruby code. But whereas this other test, it's complicated and it needs JavaScript and we need to run this as close to the user experience as possible. Sorry. We wanted to run everything from the user's perspective, just like WebRAT did. That was sort of our goal when we set out. And the result of that goal was this library, our world called Capybara. So Capybara is a simulator which simulates the user's behavior when interacting with your application. And it uses the same or very similar DSL to WebRAT. But what happened was that I started to sort of poke around in the WebRAT internals and I tried to see if I could make it do the things I wanted to do and I couldn't really do it. Because the thing I couldn't really get at was the easy setup. And that was really sort of my main design goal with Capybara. And the DSL looks something like this. As I said, visiting pages, filling in stuff, clicking buttons, checking for content and so on and so forth. It allows you to switch pretty seamlessly between drivers. So you can say that this one test, it should execute in a pure Ruby environment, this other test, it should execute in Selenium and this third test, it should execute in NFJS or whatever. Over the past year or so, there have been a really huge number of Capybara drivers released. If you were here for the lightning talks yesterday, you maybe saw Terminus, which is a pretty cool Capybara but the ones that we've used to great success have been these four. The top two are the ones that are built into Capybara right now, Rack Test and Selenium. And Rack Test is pretty fast and simple. It's a pure Ruby implementation, which means it has no JavaScript support. Selenium, you know, remote control does JavaScript and CSS. It's slow. And this Akefalos, which is unspellable and unpronounceable, I still have no idea how to actually pronounce that. I think we need some Greeks. It's headless. So it has fairly good JavaScript support through HTML unit, but it's pretty slow. And Capybara NFJS is a pure JavaScript implementation, so it's actually written in JavaScript. But as you can imagine, it's not really that compatible. It doesn't really cover the full extent of the DOM, so it's only of limited use if you're doing a really simple JavaScript. And you can switch between these just simply by specifying Capybara current driver is whatever, Selenium in this case. So after this, your test will execute in Selenium. And you can even do this in Cucumber. You can tell Cucumber to, by using these nice tags, that this particular scenario should be run in Capybara and does all this in the same test run. So you don't have to have separate test runs for using Racktest or Selenium or whatever. It's adorable, isn't it? So let's talk a little bit about unit testing. We have a ton of different solutions for unit testing JavaScript. And what they really have in common is that it's incredibly hard with most of them to get started. They usually put a lot of code into your project. I personally really dislike that. They often bundle themselves into your project. So they put the actual testing library into your code. There's really sort of no best practices established for how you're going to go about. They're really hard to maintain. And that's mostly due to that most of these libraries really lack this isolation of tests. And what I mean by that is that if you're writing multiple tests, the results of one test will affect the next one. And that leads to your test being dependent on the order which they are running. And I find that this is incredibly brittle. We also have a problem that many of these test frameworks are kind of unstable. They're written sort of as a hack by people who just really needed to solve the problem of JavaScript testing. And they wrote this framework and then abandoned it a month later. And it turns out that it's pretty buggy. And it doesn't really have a very clean implementation and so on and so forth. So the entire experience of writing JavaScript unit tests is pretty unpleasant. And a big part of that to me is that it's the syntax often is just ugly. Writing tests in JavaScript just doesn't have that same sort of Zen-like feel that if you're using RSpec you get these nice blocks and descriptions and everything. And it just looks clean. And in JavaScript your test code is just littered with unnecessary punctuation and function statements. And even for the test frameworks that have the nicest syntax it just doesn't look very good. So as I said the implementations are buggy. And we looked at all this and we really wanted to find a good solution. We really wanted to find a way of testing our JavaScript unit test that made us actually do it. Because that's what we weren't doing. We tried five different solutions and all of them we used for a month and then we just decided that this was too much of a pain in the ass and we wouldn't want to do this anymore. So again tying back to the same thing as with the integration test is the easy setup. We need to get people to actually get going with this in order for them to write tests. And we really wanted to have that sort of opinionated solution. We found a lot of solutions which were solving a very specific problem. And we didn't really want that. We wanted this sort of solution that works for the 90% case. That for most people would solve the unit testing problems. We didn't really want to want to cover everything. So we didn't want to build anything huge that covered all the edge cases. But we wanted something that was good enough for the majority case. And we wanted it to be really well packaged. We wanted this to be as standalone as possible. We wanted there to be no setup, no code in our projects. It should not add any files to your project. And that obviously makes it easy to upgrade because all the code would be contained in that one single package. Basically we wanted just a Ruby gem. We wanted a Ruby gem that you could throw into your application, bundle, install and go. We also wanted this solution to be a very easy to run. That was one problem we experienced. We wanted this to be able to run in the browser because that gives you the fastest feedback loop. And when you're developing, that's really important that you can run your tests pretty much instantly. We wanted to be able to run this from the command line so that we could integrate it into our existing workflow so that we could run it on a continuous integration server and so on. And we wanted this to be able to run against multiple drivers. So one problem we found with many of the solutions was that they did come with a command line interface, but it only ran against Selenium. And they often wrote that, yeah, we have this theoretical support for other solutions, but it never actually materialized. So we wanted a solution that could, as you saw before, we have lots of different ways of running JavaScript code from the command line. But they all have their drawbacks and their advantages. And we wanted to be able to choose by project which one we were going to use. So what we came up with is this solution, Evergreen and Jasmine. So we chose what we found to be the best sort of general purpose JavaScript testing framework which is called Jasmine. It's written by Pivotal Labs. And this was really just simply what we liked best. We found that this was stable. I've yet to find any kind of bugs in it to be honest. It's pretty small and doesn't have a giant code base, but it does have all the features you'd expect. It even comes with built-in mocking framework, or spies as they call it. And it's general purpose. You can pretty much test anything you want with it. But that's also kind of its downfall. Because we found this really great testing library and we thought, yeah, let's use this for testing our Rails applications. The JavaScript and our Rails applications rather. And then we just did that and we're like, yeah, but how do we do that? And we couldn't really find a good way. It does come with a Ruby gem which is supposed to integrate it into your Rails applications. But just reading through the instructions of it, it's just, it's so complicated. There's lots of steps to getting it set up and it just, it didn't really work that well for our needs. So we wrote this sort of testing harness called Evergreen. And we think it's really cool. So what it does is it has no generators. It doesn't add any code to your project and there's no setup. And that's really what we wanted to get. It does work great with Rails. You just add this line to your gem file and you bundle install and you're up and running. It's however not tied to Rails in any way. And that was really one of the other things that we thought was really important. We wanted to test framework that would allow us to test JavaScript in a Sinatra app that would allow us to test our JavaScript even in an application that doesn't use Ruby at all. Or when we're building a standalone JavaScript library, like some kind of JavaScript widget or something. We didn't have a solution for that. And the existing solutions we could find, they would always tie your JavaScript tests to Rails. And we really wanted to have a nicer syntax. And at some point we found CoffeeScript. And CoffeeScript is a language which compiles down to JavaScript. So it's its own programming language but it's very similar to JavaScript. Basically with nicer syntax. And we integrated this from the beginning into Evergreen so that it would allow you to write your tests in CoffeeScript with this beautiful syntax. And you wouldn't ever have to be bothered about having to write function on every single line of your test code if you've ever written JavaScript tests. You probably know the pain of that. And one thing we really were sort of pain about with many solutions was the notion of templates. Obviously when you're writing JavaScript tests that's supposed to access the DOM, you need some kind of DOM to work against. And the usual solution to that is to have a static template which would include your JavaScript test framework and the test code you were using. And whatever HTML you would need to test against. And the problem we found with this is that you add a lot of unnecessary glue code to that template. A lot of code that you don't really need in the end and that just sort of gets in the way and becomes hard to maintain. So what we did instead is we just did these template fragments. So this was just our templates just include the actual HTML that we're testing against. They're reloaded for each test which means we have one specific div on the page which we dump all this HTML into and for each test run that div is emptied and the template is copied into it again. So that each test we're writing is isolated from the others as long as you stick to using only that div. And that really makes it very nice to sort of isolate your tests one from each other. And for running your tests we could run them in browser just by going to slash evergreen and that's a sort of default in Rails and in another framework you would have to manually mount it at a particular URL but for Rails it's mounted at slash evergreen so you can just go there, you can click on a particular spec and it will run that spec. We'll show you that in a minute. You could run them from the command line just by using rake or by using the built-in command line interface. And we built this using Kappibara obviously because that's what we know and we made it so that it can use any Kappibara driver. So you can use Selenium to run your unit tests or you can use NFJS if your code doesn't do anything fancy that wouldn't work in NFJS and so on and so forth. And that's it really. So let's show some code. We've created a very, very simple demo application. I'm just going to start by showing you the app. It looks like this. It's a whiskey browser so we can select our favorite region and show the distilleries in that region and we can select a distillery and show some of its spot lengths that it has produced. So this is a very, very simple application. No JavaScript as it is right now. To test this we have, let's see, let's get rid of that. We're just using normal R-spec integration tests and we're also using just to show in this example Cucumber as well. Probably wouldn't do both in a real application. That'd be kind of overkill. So again this is no JavaScript at all, just normal Cucumber or normal R-spec integration tests. Using Kappibara. Using Kappibara, right, but without JavaScript. But the user interface isn't really that good. I mean we're going to be relying on this application heavily. So we want to get rid of these annoying buttons when we're browsing. So we have a different branch of the code here where we've added JavaScript support. So in this case the buttons are gone. We select the region, select the distillery, same behavior, but way faster. So that's good. Now how do we test this? If we check our R-spec integration tests, we've added, actually let me get this higher up on the screen for you. So we've added a separate statement here. Can everyone see that? Good. So if we see the one without JavaScript here first, this is still using using Kappibara. So we're just saying visit the root path here and then select ILA from the region. We're clicking a button, selecting a distillery and clicking a button again and then checking for content. Now with the JavaScript the only difference here really is this part, way out to the right here. So we just say pass in js true to the it statement. That enables, that will make sure that this it statement or this code will be run in using a driver that is JavaScript compatible. And it's using, in this case the default JavaScript driver which is Selenium. But you could also configure it easily to use anything else. So the only difference here is that I've just simply removed the button clicks. So we're, the only thing we're doing is visiting the root path, selecting from the first select menu and then selecting from the second select menu and then checking for content again. And if we run this, so we can just run our spec. Good call. There we go. So we'll run the acceptance or the test in the acceptance folder here. So it runs the first one very quickly because that's without, without JavaScript. The second one takes all to load because it has to launch Firefox and, and gets Selenium going and that's the overhead of, of using Selenium there. But it runs and everything works. We can quickly just see what happens if we remove this and run it again. And we get a failure now because there is no art big option and it's still remaining because that hasn't been loaded if we're not using JavaScript. And I'm not going to show the Cucumber. This code will all be available on GitHub so you can look at it yourselves later if you want. But it's exactly the same thing just using the Cucumber's plain text and then using tags to switch, switch to the JavaScript driver. Now those were the integration tests. We also have the unit tests. So if I go to the slash evergreen path in the application, I can see that we have two unit tests here. And one for the region menu and one for the distillery menu. And I can run either one just by clicking on it. If I select show past, it shows me all of the unit tests here. And in this case, maybe a bit contrived example, but I'm actually unit testing the AJAX as well with Mox just to get some example code in there. And I can run the other one and it passes as well. So using the browser like this gives you a very, very quick feedback loop. It's very easy to just to rerun the test here. Just have to reload the page and they run. So if I don't have to wait for Selenium to start to run the test, et cetera. So this is the very, very important quick feedback loop that we're after when we're using TDD. But of course, that's not going to work in a continuous integration environment, for instance. So we can also just run them from the command line, running rake spec JavaScripts. And this will launch the Kappa Barrow driver and run it in the background. So that works as well. So what does this look like? In our spec folder here, we have a JavaScript folder and this is where the tests are. So as Jonah said, Evergreen doesn't add any code to your project. It's just a gem that you include in your gem file. And then you simply create your spec files in the spec slash JavaScript folder. And by having them end on underscore spec dot js, Evergreen picks them up automatically and runs them for you. And everything in this file is jasmine, really. We have some additions with require and we can also load templates through Evergreen here. But other than that, this is just normal jasmine. But it's still quite noisy, as you can see here. There's still all the anonymous functions that you have on every single line in your JavaScript tests. And that's not very pleasant as we talked about. So what you can do is you can write your specs in CoffeeScript instead, as Jonas mentioned. So I'll just switch to another branch here and now remove the spec dot js files and instead have spec dot coffee files. And again, there's no configuration for this. Just name your files dot coffee instead. And Evergreen will take care of the rest for you. And this is exactly same tests only written in CoffeeScript instead. So you can see it's, if you haven't looked at CoffeeScript, I'm going to encourage you to take a look at it because it's really very, very nice, especially I find when writing tests. Instead of having to write function on every line, we have the stabby lambda syntax that we have in Ruby 1.9 and it just leads to cleaner code with less noise in it really. And it runs exactly the same. If I go back to Evergreen and the browser here, you can see it has picked up the dot coffee files and I just clicked them and they run in exactly the same way. So that's really all there is to it for the demo. Again, we're making the code available so you can have a look at it, play around with it and see what this looks like in practice. So with that, we have just a few minutes left for questions. So I think if anyone has a question, you can either come up to a mic or just shout it out and we'll repeat the question. Yes. Sorry? For Kappabarra? So the question was, are there any plans to support test unit as well in Kappabarra? And Kappabarra already supports test unit. You just need to include Kappabarra in your test case class. It currently doesn't really have any special feature for sort of switching between drivers like it does in Aspect or Cucumber. So you have to call that manually. But other than that, it already does support test unit. All right. So the question was, how do you deal with the templates potentially getting out of sync with the code in your view? And for us, we found that the best solution for us was sort of to not deal with that at all. And what I mean by that is, you have, if you have your integration tests that sort of test how your components interact with each other and your JavaScript components that your unit testing are sufficiently isolated, then we found that it worked better for us to not have any kind of sort of syncing of templates or anything like that. We actually tried that in the beginning. And we found that it didn't really work quite as well as we hoped to. So in that case where we find that it would really be nice to have that, it would probably make more sense to write an integration test than a unit test. So basically you're treating your templates as fixtures and relying on the integration tests to catch any when they've come out of sync, basically. Anyone else? Yes. So the question was if we can talk about how the Selenium driver and recording video of your tests. And I don't know. I've heard a lot from different people who capture screenshots when the tests fail. I haven't actually seen anyone record an entire video of the test. I guess it would be doable if you have a scriptable application which records your screen somehow. Must exist. I don't know anything about it. Do you have anything to say? PDI. Standard answer. Any further questions? So where will it be? Yes. Thank you. Well, with that, I'm going to encourage or we're going to start drinking for the day, I think. These are the most awesome teppie bars you'll ever see, probably. They smoke cigars and drink matinis. One could be more awesome than that. Yeah, so thank you very much for coming. We have some resources here for you to check out. And I just see that Markdown has screwed up our formatting here. Yeah, it's supposed to be underscores in between. Yeah. So if you go to github.com slash elabs, there's a front-end testing repository there that has all the example code. Check out Jonas's GitHub page for Capybara and Evergreen and, of course, Pivotals for Jasmine. If you have any further questions, this is actually wrong as well. I see now. Let's see. Ping us on Twitter or something like that. Find us here and we'd be happy to talk with you. Thank you very much. Thank you.