Acceptance Testing

[00:00:00]
>> Mike North: The next thing we're gonna do is add an acceptance test. Acceptance tests are designed to imitate user behavior. So we should be thinking in terms of what would the user do in order to go through a particular workflow? You should be thinking in terms of type in the following thing into this input.

[00:00:20]
Click on that, double click on this other thing. That's the level of granularity you want in an acceptance test. If you find that you're trying to reach into a component and observe some non rendered stage or something like that. That is a sign that you may be going outside of what an acceptance test is best at doing.

[00:00:39]
I love the way Ember allows us to write acceptance test, they're like human readable which is wonderful cuz that's not often the case. Maybe I'm just scarred from some selenium historical damage that has been done but it's rich really nice point in Ember Octane. So, we can generate an acceptance test with Ember CLI.

[00:01:05]
Ember, generate, acceptance test, and we're gonna call this one log out, right?
>> Mike North: And we can see that our tests fail on the right, that's okay. We're gonna fix that in a moment and get rid of this for now. So we're gonna go to tests, acceptance and log out test.

[00:01:34]
This is our starting point. And the starting point for an acceptance test gonna take the name of the test and assumed that is a particular URL that you wanna visit. We don't have a route called log out. But log out definitely describes what I'm about to test. And that is the following.

[00:01:52]
I wanna visit the teams page, I want to assert that we successfully arrived at that URL. I wanna click on the log out button, and then I want to assert that we have reached the log in screen. Even once we add some authentication on top of this, that condition should still hold through.

[00:02:14]
Go to teams, click log out, you should find yourself at this screen, right? So eventhough we're gonna build on top of this this is still a valuable test to have. I'm gonna change the name of this task module. And that's just this string here, right? This string is coming from here so I can just make this logging out.

[00:02:36]
And we'll call this test, which is this piece here, right, that's visiting/logout, we can call this visiting teams,
>> Mike North: And clicking logout.
>> Mike North: And now there we go, acceptance, logging out, visiting teams and clicking log out. So if someone got in test reports saying that this failed, we've now left a very good clue, is to what this is all about.

[00:03:12]
So the first step we gonna do here is were gonna work with visit and visit is one of Embers test-helpers. So this module up here, Ember test helpers, that is where you gonna find things like, go to a URL by visiting. Get the current URL to assert if you actually arrived there.

[00:03:31]
There's a bunch of other stuff in there, like fill in an input, find an element on the screen, click or lose focus or gain focus. These are all things that kind of imitate a user either typing something in or tabbing around and selecting various, like focusing on various elements within the screen.

[00:03:52]
So this is where you wanna reach for these user interactions. And most of them are a sync functions where you can await them. And the benefit of this is if we have to fetch data as a result of going from one route to another route. This will pause your test and wait for everything to settle before you start to make your assertions.

[00:04:18]
So it lets you pause at the right times and then make whatever synchronous assertions you need to make in between those potentially asynchronous steps. Like visit a URL, click on something, fill in something, etc. So we'll begin by visiting teams. And I'll leave a comment here, go to the /teams url.

[00:04:41]
And we're gonna assert that we've arrived there.
>> Mike North: And now the test starts passing. Let me zoom out. I'm gonna just filter for acceptance. And that way we don't have so much noise going on in the right side. So we're going to /teams. We assert that we have, in fact, arrived at /teams.

[00:05:03]
So if there were some error thrown, or we were kicked because we're not authenticated, this would've not held true, the assertion would not have passed. We're going to click on the appropriate DOM element, so I'm gonna open up a new tab and go to /teams. I just wanna figure out for that logout button, what is the selector I want to use?

[00:05:32]
>> Mike North: It looks like we've got teams-sidebar_logout button there. So I'm gonna grab that.
>> Mike North: That seems like it's unique enough that it should only apply to that button and not accidentally to other things. So let's say await click. This is gonna auto import click from Ember test helpers or should.

[00:05:56]
Guess not, we can do it manually. Pass in the selector that we wanna click. And, then I'm going to assert that the current URL is login. And the test passes, so seems pretty easy. Seems like this is again very semantic. Each of these lines has a meaning, right?

[00:06:30]
Click the logout button and then asserting that URLs are as they are. I wanna show you kind of what's going on. We can put debuggers in between these weights. There's a great way to shake problems out of these tests. And I wanna focus on this iFrame at the bottom of the screen.

[00:06:54]
>> Mike North: Let's try again. Here's the iFrame.
>> Mike North: Come on, zoom out. There we go. So here here's our test runner UI and this is our actual app. It's formated oddly but who cares. But it's at this particular URL and it's rendered so we can see it's running our app for real.

[00:07:19]
The whole app in its entirety. And if I were then to set another debugger.
>> Mike North: Sorry this is a very thin line to try to grab. Just set another break point here and let's play forward. I can see that we're at the log in screen now. So you can a sync in a way make it very easy to stop at various points.

[00:07:45]
We might have just started writing this test and figure it out what's that button? What's the correct thing to find for that button, right? What's the class I wanna click on. It would be very easy to just get to a point, need more information, debugger, and you can just drill into this page, just like you would drill into anything else.

[00:08:05]
Acceptance tests are a little bit slower than other types of tests. There's three orders of magnitude slower than unit tests, so don't get all of your release confidence with these. But these are excellent for protecting critical workflows from regression. And for something like this, I would not reach for anything else.

[00:08:27]
This is the ideal kind of test for a login or logout workflow and make sure everything's copacetic.