Check out a free preview of the full Build Web Apps with Angular 2 course:
The "Writing a Component Spec" Lesson is part of the full, Build Web Apps with Angular 2 course featured in this preview video. Here's what you'd learn in this lesson:

Lukas demonstrates how to write a spec for his Users component. He creates a spec file in the component’s directory and adds a simple assertion. After the spec is written, he runs the “npm test” command to initiate the Karma test runner.

Get Unlimited Access Now

Transcript from the "Writing a Component Spec" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Lukas Ruebbelke: So one other thing, I'm tempted to do this live but I don't know the interface so it would be a lot of, what did I do over here? I'm gonna copy it over, I guess I will. So let's write a spec for this. With that, full disclosure, I am going to copy a spec that I've wrote over the lunch hour and just kind of talk through what I'm doing and we'll just work through this together.

[00:00:29] So in this project, if you go npn.test, it's going to kick off karma and we're using authentim.js, which is a headless browser to go run its test against and I have three passing tests. So I have one in AppComponent and two in HomeComponent. This may be a little small.

[00:01:01] I saw somebody craning their head, I apologize to that. And so let's do one for users. So we'll go new, type script file, we'll go usersComponentspec.ts. Nope. And so the first thing that you need to do is import your Jasmine methods that you're going to use. And so this comes right from Angular 24/testing, so we'll do describe, expect, it.

[00:01:40] Then, we're going to import our component that we want to test, which is users from
>> Lukas Ruebbelke: Users component.
>> Lukas Ruebbelke: Then, I wanna say describe.
>> Lukas Ruebbelke: I'm just gonna cheat here a little bit. And I'm gonna cheat a lot actually. Don't get mad.
>> [LAUGH]
>> Lukas Ruebbelke: Yeah. No, what happened?

[00:02:14] Dang it. Gosh. All right, I'm back on track.
>> Lukas Ruebbelke: Users Component here. So let's write a test. -> here and we'll go it should be named
>> Lukas Ruebbelke: UsersComponent.
>> Lukas Ruebbelke: Like so, make sure, yep, so, another fat arrow in here. Now you realize by me actually doing this, you now have to do this in the code challenges.

[00:03:06] Just saying. All right, so let's write our assertion, expect(Users.name).tobe('Users')
>> Lukas Ruebbelke: I think I got this. I'm getting some, all right.
>> Lukas Ruebbelke: If this actually works, and I get this test to pass, Scott's gonna do the robot for us.
>> Lukas Ruebbelke: And if I was really truly doing TDD here, then I would've actually made this fail first but, [SOUND] boom.

[00:04:01]
>> Lukas Ruebbelke: I know that's, man, I was so tempted just jump there and sing with you. So, my work here is complete. Components with life cycle hooks and a test. Any questions before I drop the co-challenge on you?
>> Lukas Ruebbelke: Yes sir, in the back.
>> Speaker 2: Question from chat. Is there any way to get resolve functionality in component?

[00:04:29] So to prevent it from firing up before it gets results from an API call?
>> Lukas Ruebbelke: I do not know. So in other words, you're saying a blocking operation of in terms of component router or not component router but in Angular 1 you had, in this route, I have this promise that has to resolve before it renders.

[00:04:54] I do not believe there is a mechanism in place currently to do that.
>> Lukas Ruebbelke: Yeah, I haven't heard of any kind of resolve, route resolve functionality. Next question.
>> Speaker 2: Just to go deeper into that question there, isn't a resolve, but again tying into, this all happens around routing so there isn't a resolve on the current router, but the router has lifecycle hooks that you can tie into so you would use those lifecycle hooks to prevent a component from being rendered by the router.

[00:05:29]
>> Speaker 3: So, those lifecycle hooks can handle asynchronous operations?
>> Lukas Ruebbelke: And so, we'll get a lot more into this over the next couple of days. A couple of things is one you have the Elvis operator to say don't render this thing until this exists. In other words, so it's this optional thing of, if this doesn't exist, then just don't do anything with this yet.

[00:05:50] Is well as by using the async pipe which is really, really cool, you can say, when this asynchronous thing comes in from your service as a promise or an observable, then go ahead and render this. And so it's really cool because you can actually bypass the component altogether and you not just say.

[00:06:09] With a promise, it's like, make this call then, and then you say, you take the payload and you assign it to a property, local to your local state within your controller in Angular 1. You can still do it that way, but now using observables, you can simply say, hey, service, go give me this thing.

[00:06:29] And it's returning an observable and then you can bind to that thing directly using the async pipe it will just render when it happens. So to that I think the lifecycle host really take care of a lot of that and I would much rather have the ability to hook into the lifecycle as opposed to doing a blocking operation on a resolve.

[00:06:48] And with observables, you take it even a step further of you just say, I'm gonna push this to the view when this is ready and I don't have to block anything.
>> Speaker 3: Yeah, there is a can activate lifecycle hook for the router that gives you access to the current parameters and the next component that's trying to render.

[00:07:13] And from there, you can return true or false even after asynchronous operation. True, which means go to the next component being routed. False means stop routing. So that's what you would use. But there really isn't an elegant way of getting the result of that promise onto the object for the next route other than tying it to the next parameter.

[00:07:32]
>> Lukas Ruebbelke: And that really, so that mechanism is good for authentication. In other words, can I even go to this route? You can simply say, do they have, for instance, a jot, a token, does it exist, are they authenticated? Okay, let them go. And so having that ability to hook into that route event is good for that but actually passing data and blocking data to pass it into the next like route change, I'm unaware of anything at this point.

[00:07:59]
>> Speaker 3: Yeah, I wouldn't do that, I would stay away from that pattern, then you'd have messy state