So you might be wondering why I'm here, and well, we

swapped the talks. So the scale you see outside is a little bit off. So the next talk would have been, or actually this talk would have been about writing custom test helpers with the new APIs. But I'm going to introduce those new APIs now. So it makes a lot more sense. So this talk, as I said, is about the next generation

of testing in Ember, although right now we already have that generation. So it should actually be the current generation of testing. But I'm still going to introduce you to it. So this doesn't work. No, it does. OK, so this is me. I'm actually glad I parted in my spare time. So if you have any questions about that, ask me after the talk.

But also if you have questions about the actual content of the talk, you can ask me about that too. You can see the handles at the bottom if you want to contact me otherwise. I work in Germany for simple apps consultancy in Munich. We do consulting all over Europe, basically, just like Jessica, who just presented to. I do have some Ember Jazz Munich stickers with me.

So if you want some, find me after the talk. But you may also know me from my work on Ember CLI. So you can see I have a problem, open source style problem. I maintain quite a lot of packages at this point. So the first thing I want to talk to you about is the and then helper.

And it was already mentioned in a keynote this morning. And then is pretty much no longer a thing. If you don't know what and then is, it's this thing. So when you write acceptance tests, you use the visit helper to visit a route. You can use fill in and click to interact with that route.

You can basically simulate UI actions from a user. And at the end, you use the and then helper to run assertions on that state. So what the and then helper does is basically wait for any asynchronous actions to finish. So imagine when you do the click, the submit button

click, that that would fire off an AJAX request. Now, the and then helper would wait for that AJAX request to finish until it goes on and then runs the assertions for you. But the and then helper is not exactly standard JavaScript. And it was invented actually five years ago.

If you look at the code as it was in 2013 when testing was first introduced into Ember, you can see promise chains. And if you look at them, they're not exactly readable. It's quite noisy and boilerplatey. And it takes your focus away from the actual code that you test.

So the and then helper was basically invented to work around that problem that promise chains are essentially very verbose. But as it is on the slides, that was 2013. We have 2018 now, so five years later. And TC39, I think last year or two years ago,

introduced async functions. That makes it a lot easier to write asynchronous code. And if you compare the promise chains to async await, it looks like this. So a lot more obvious what's going on. The async parts of the tests are clearly marked with the await keyword.

So basically, all you have to do in front of the function, you write the async keyword. And in front of all the asynchronous helpers, you write await to await until that promise has finished. And then the control flow will just continue. So in summary, and then almost five years old,

it mixes synchronous and asynchronous code in a way that is kind of hard to follow and understand. And it has a somewhat unintuitive API. While async await, it is standardized ECMAScript now. It is very explicit about what calls are actually asynchronous. And it's based on promises, so another standardized feature

of JavaScript. Onto the next topic. jQuery, you've already heard it in the keynote. Ember doesn't use it anymore. So why do we have it? Well, there is one caveat to the announcement in the keynote because, well, the test servers, they still use it internally.

So it's kind of hard. If we look at example snippets, you can see an acceptance test snippet at the top and a component integration test at the bottom. And just look out where jQuery could be used in those snippets. In some cases, it's somewhat obvious. In other cases, it's not.

You can see at the bottom, there is a this.dollar sign, which is usually a good indicator that jQuery is used. There's another one. But did you know that the click and find helpers are also using jQuery underneath? So that's basically the reason why jQuery is still somewhat needed. But I'm going to show you how you can work around that.

So if we focus on the top snippet, you can see the click and the find helper. And basically, all we need to do would be to write a function that has the same API as the current helpers, but uses native DOM elements and native DOM APIs underneath.

So thanks to Miguel Camber, CyberKnox, thank you. We have Ember native DOM helpers, which does exactly that. So instead of using the global click and find functions that we include for you, you can just import click and find as examples from Ember native DOM helpers and use those instead. And they will just use native DOM APIs,

so you no longer rely on jQuery at all. There is one minor caveat. The find helper, the global find helper actually returns a jQuery object. Since we don't use jQuery with the native DOM helpers, we can't actually do that, which means we actually return a native DOM element.

So there is a slight problem there, but it's actually easy to work around, because the native DOM APIs at this point are quite all right. So at the end of last year, we started extracting those helpers into an official add-on, and that is Ember test helpers, as you can see here.

So basically, those are more or less the same helpers. There is one minor difference, though. The Ember test helpers only work with the new testing APIs. The native DOM helpers work with both, which makes it great as a sort of intermediate step towards migrating to the new APIs.

Next topic, nested modules. I'm actually a big fan of Mocha. I've been an opponent of QUnit for quite some time. I had quite strong feelings about that. At this point, I must say, QUnit is OK. I can work with it with the new APIs. Anyways, let's get into nested modules. If you have never used Mocha, this

is basically what they look like. So what it means is you can basically nest test suites in one another. And the reason for doing this is that each of those test suites can have setup and teardown hooks that got invoked for every test in those test suites. It's a very simplified example, but you

can see how that would scale, basically, if you have a lot of tests in those. So one thing that annoyed me always about QUnit was you could not do that, at least not for Ember. Luckily, last year or so, a new QUnit version came out, and it actually allows us to do those things.

So if you compare the current Mocha code with the QUnit code, it looks like this. It's basically the same. There are a few naming changes, and the hooks object is more explicit than in Mocha, but it's pretty much the same other than that. There is another caveat, though. This does not work with our current APIs.

So we usually use module 4, module 4 component, module 4 model, module 4 acceptance in Ember tests, but those don't allow us to nest that, which I'm not a fan of. So we took a stab at solving that. And Rob came up with an RFC about, I think,

two years ago called the grams testing unification. It's been around sometime, and it was RFC 119. And if you look at the RFC, it is long. It's actually very long. So it had quite a lot of content,

and nobody actually dared to implement it, because the scope was just so big. So two years later, nobody had still worked on this, basically. So we started extracting out several smaller scope RFCs out of that. And the first one is RFC 232, add new QUnit testing API.

And the TLDR of this is that we replace the module 4 functions with the native module function that QUnit exports, plus a somewhat custom setup test function that basically integrates the module with the Ember testing setup.

There is a sibling RFC which is 268, and that basically does the same for acceptance tests. So instead of writing module for acceptance, you now use the native module API of QUnit, and you use setup application tests inside of that. I will go into all of this. So we basically now have four different ways

of writing tests. And I will dive into that now. So the first kind of test you can write is a plain QUnit test. That's basically for code that is entirely unrelated to Ember, so say a utility function that doesn't actually know about services, routes, components, whatever. Example code is like this.

You have a module and a test function that you import from QUnit. Notice there is no Ember at all on this slide. It's just a regular, plain QUnit test. In this case, we're testing the relative date function. We're passing something in, asserting on the output. And it's just you could basically find this example on the QUnit home page

because it's nothing special. There's no Ember specific stuff in it. The next thing you can do, and more regular thing you can do, is write container tests. I've put that in quotes because Rob told me to not name it that way. The thing is, though, that we both couldn't come up with a better name so far, so I still continue using it.

You can use container tests for controllers, routes, services, stuff like that. Basically, everything where you previously used integration or unit tests. And I'm going to go through a quick example. By the way, don't be scared about all of the code. I will publish the slides in the select channel afterwards.

So you can just go through it at your own pace later. So the first thing we do in this example is we import stuff. So you've already seen before we import the module and the test functions. All these are just the regular QUnit APIs. And the second thing we import is the setup test function that I mentioned. Next, we set up a test suite, and we

run setup test as the first thing inside the test suite. Notice this is not running as part of a hook, but this instead is setting up the hooks. So that is why we pass in the hooks object into the setup test function. This will be a very common pattern, so get used to that from now on.

It's basically the same in Mocha, by the way, where we have pretty similar APIs at this point. This setup test function makes the testing container available inside of tests. And what that means is inside of the test, you have access to this.owner. This.owner has a method called lookup,

and you can use that to look up basically everything that's on the application container. So stuff like services, controllers, routes, technically even components, although components should be tested in another way. And finally, once you have an instance of, say, the flash messages service in this case,

you can use that to assert stuff like properties, method calls, and whatever you want, basically. So to recap, import from QUnit, import from Ember QUnit the specific stuff, open a test suite, run setup test, and after that just write test, and you use this owner lookup

to look up whatever you want to test, basically. You can also look up other things. So in this case, we're writing a test for the flash messages service, but no one's keeping you from looking up other things. So if you imagine you're using Ember Intel, for example, and you want to change the language that Ember Intel is using, you can basically

look up the Intel service from the container, use set locale, and then that will just work. So next type of test, rendering tests. That is basically what was previously the component integration tests. And you would use that for testing components and helpers. And it looks like this. Roughly similar, except in this case,

we're not importing setup test, but setup rendering test from Ember QUnit. And we're importing render and click from the Ember test helpers add-on. Now you might be wondering, why are we not just importing that from Ember QUnit? And you're right. But the thing is, that also works with Mocha now.

So the only test framework specific stuff that we do is actually the setup test functions. Everything else works, whether you use Mocha, QUnit, maybe some other test framework in the future, we'll see. So you import these things. The HPS import is just the same like we've used before. And then you open a test suite.

And in this example, you're not calling setup test, but setup rendering test instead. But everything else is exactly the same, essentially. And setup rendering test is actually using setup test underneath. So that means you can still use this owner.lookup, for example, in the tests.

And everything will just work the same as in setup test, basically. If we look at the test, it uses an async function. So no and then anymore. I don't think and then is even supported in these kinds of tests anymore. You can use promise chains if you want to hurt yourself. But I really would recommend to you just use async functions.

And it is the default in MLCL3 right now. So as you can see, we are calling the render function. We're passing in a template, basically rendering an x counter component, for example, yet. And we are awaiting the render function results.

The reason why we're doing this in the keynote today, you heard about async rendering. And that is basically incrementally rendering over multiple time slices, more or less. And if we would just continue synchronously, the template might not actually have finished rendering. So that is why in this case, in the new APIs,

we are explicitly, asynchronously awaiting the result of the render function. After that, we can just run assertions like we would normally do. We can use the click helper in this example to click on the counter, run assertions again. And it just works, basically. The fourth kind of test we can write

is an application test. It's basically the same as an acceptance test before. And you can just use those to verify user stories, basically. The testing code looks almost the same. In this case, set up an application test, not set up rendering test. We import mostly the same test helpers,

which is another big advantage of those new testing APIs. Because before, in integration tests and acceptance tests, used entirely different code, basically. Now it's almost the same. The only big difference here is we are not importing the render helper. We are importing the visit helper. And if you look at the testing code, well, I mean, we use set up application tests.

That's obvious by now, I hope. If you look at the actual test code, it almost looks the same. We are visiting a route of your application. After that, we're filling in some stuff. We're clicking a Submit button. We're waiting for that to return. And then we just run our assertions as normal. So actually, pretty straightforward, at least for me.

Sorry. So at this point, you might be wondering, how can I get this? This looks nice. I want to have that. What do I have to Ember install to get this? And the good news is you might already have it, because it doesn't actually depend on your Ember version at all. The only thing that matters is your Ember C, like Huion,

needs to be on version 4.2 or above. And if you have that, you can just use the new APIs already. Whether you're on Ember, I don't know, 2.0, I think we test all the way down to 2.4 or something. So if you're above that, you should be fine. Also, you might be wondering, well, I already have 5,000 tests or so.

What about those? How can I migrate those? Because that seems like a lot of work. And you're right. So I got a high-level migration plan for you. The first thing is migrate to using async await instead of and then. Async await works within the old APIs, too. So that's a good first step, basically.

The next thing is use Ember Native DOM Helpers. As I mentioned before, it does work with the old APIs and the new APIs. So that's a really good intermediate step. But that's still a lot of work. Great news. We have a robot, or a code mod.

It's called Ember Native DOM Helpers Code Mod. If you run that, it will automatically transition you to the new APIs, well, to async await and the native DOM helpers. Disclaimer, code mods are never perfect. But we really do our best. And I've had great success with this code mod. It basically converts like 95% correctly.

And the 5% is usually something you can do manually. The next step is using the setup test functions, or the new testing APIs. And while that's still a lot of work, we also have a code mod for that. It's called Ember Q Unit Code Mod. There is a similar thing for Mocha,

although it's not entirely finished yet. So give me a week or something. We're hopefully going to be finished with that, too. That also has a quite high success rate over all the projects that have migrated so far. So pretty good. And then the fourth step is basically just cleanup. In most cases, you can just rename the Ember Native DOM

Helpers import to just use Ember Test Helpers. You might have to adjust some things here and there. But also for that, there's a code mod. So technically, you don't have to do anything. You just have to run those three code mods. And hopefully, you're just done after that. So that's good. I got another section which is called Tricks.

We have about 11 minutes left, apparently. So I'm just going to go through that now. Mocking. There seem to be quite a few misconceptions about how to mock properly in Ember. And Ember is using this thing called a dependency injection model, more or less.

And that is actually meant to be mocked, more or less. So you can just register different things on those dependency injection containers, and that will automatically mock stuff for you. So I have an example of this. In this case, we're registering a mocked cookies service. And we're just saying, if someone reads cookies,

whatever key it is, we just return ABC delimited by semicolon. Next, we're just going to look up, say, a feature service that uses the cookie service. And we don't have to overwrite the cookies property in the feature service because it just injects

the mocked service for you. The only caveat here is you need to register that thing before you look up anything that uses it. Because if you look up before, the injection will already have happened. And if you register the mocked service after that, it will not matter because it won't be used.

So keep that in mind. If you mock something, mock it before you look up stuff. That's important. After that, you can just use the feature service as you would and do assertions on it, do whatever you will. All in all, not much code, and it works quite well, actually. Another thing is loading states and how you can test them.

I mentioned earlier that, say, if you use a wait click, it will wait for any Ajax request, for example, to finish until it continues. But what if you actually want to test the loading state of your application, say, a loading spinner? This is one example. So we visit the comments new route.

We put in a bunch of stuff into the comments field. We click the submit button. But in this case, we're not actually awaiting it. But we're saving the promise that comes out of the click function for later. Next, we're using the wait for helper from Ember test helpers. And we're waiting until the loading spinner appears on the DOM. So what this does underneath is it automatically,

every some milliseconds, pulls the DOM and checks is that selector available yet or not. And if it isn't after a timeout, I think by default it's two seconds, it will fail the test. If it's available, it will just continue. I forgot something in this slide

which is doing assertions actually after that. But you can imagine that after wait for has returned, you can run assertions on those loading states. Once that is finished, you can await the original promise from the click helper and then run assertions on the finished state. What wait for does underneath is essentially this.

We also have a helper called wait until. And that basically is the thing that's polling. So it will just run the predicate function that you passed to it. And once that function returns true, it will resolve. If that function doesn't return true after two seconds,

it will reject the promise. Another thing is custom test helpers. And that is actually the thing that Jamie will talk about in the next talk. If you've used register async helper or register helper before, that's no longer a thing. So register async helper used to look like this. You're basically, you're not actually exporting anything.

You're actually calling the register async helper function, passing in the name of the function that you're defining next. It all looks a bit weird. Also, it's using the old helpers which isn't great. What we do now is this. We just export an async function from basically anywhere you want.

I would recommend the test helpers folder, but you can basically do it wherever you want. And then inside of that, we're just using the new helpers. And we're using an async function to be able to await stuff inside of there. So that's actually pretty straightforward. As I said, Jamie will mention that in a lot more detail later.

Another thing you can do to write better tests in general is use test selectors. Test selectors is the thing you use if you look up stuff on the DOM. This is one example. You can see here we have a header, we have an input field, and we use the CSS class and the tag name to look up those elements

from the DOM for our tests. But imagine someone would like to make the H1 and H2. That doesn't really work because you now have to change all of your tests. The same for the CSS class. If you change the CSS class, things will break. That's not great. So those are the test selectors.

What you can do instead is you can use data attributes. By convention, what we usually do is we use data-test-something to indicate that this is the element that we want to run assertions on or that we want to click. And then at the bottom, you can see we have these square brackets.

Inside of that, we put the data attributes, and we just use those as selectors. It has one downside. The DOM that you will use looks kind of noisy because it will send all of that to your clients. Fortunately, Ember allows us to do AST transforms,

which means we can actually strip those selectors out if you run production builds. And as we use Ember, that's obviously an add-on, and you can just Ember install and the test selectors, and it will automatically remove all those data-test attributes from your production builds. So that's pretty good. Next thing I have is readable assertions.

That's one thing that really annoyed me about QUnit because its assertions are a lot more verbose than, say, Chai Jazz. So let's say we want to run this assertion. It's not exactly obvious what we're testing there. I mean, if you take a second, you can see we're asserting a text content.

We're trimming that. We're running the test that is this hello world or not, but it's not that readable. So last year, I thought, how can we make this better? I've been working on a client project, and we use QUnit, so I couldn't switch over to Mocha. Well, so I had to use QUnit, and I came up with this.

So this was the API I wanted to use. Because it's very expressive, you just pass the selector to the DOM function, and then you run, for example, a has text assertion on it, and you have to admit it's much more readable. So around the time of Ember Fest last year,

I sat down and spent about a week implementing this, and you can now install it as Ember install QUnit DOM, and you can see it's not just has text, but you can also assert that something exists in the DOM, that it has a certain CSS class, that something is focused, has a value, and there are several other assertions that you can use.

And I'm happy to announce, two weeks ago we merged an RFC that this is actually going to become the default in Ember CLI apps from now on. You don't have to use it, but I would strongly recommend it because it's really great, and it makes your test code a lot more readable. To finish off, have a look at the rest of the Ember

testing ecosystem. There are lots of great add-ons. I've been using quite a few of them, and they make your testing code a lot easier. Thanks to everyone that worked on this, and thanks to you for listening for me. Thank you.