Check out a free preview of the full Angular Core course:
The "Testing Wrap-Up" Lesson is part of the full, Angular Core course featured in this preview video. Here's what you'd learn in this lesson:

Lukas reviews key points of testing in Angular, and fields questions from the audience.

Get Unlimited Access Now

Transcript from the "Testing Wrap-Up" Lesson

[00:00:01]
>> Lukas Ruebbelke: I can say emphatically that the ability to reliably spin up a component in a mock module and have access to its element that it lives on for free is a major step forward. This was very, very hard in AngularJS. And now that we can come in, and any time you use the CLI in the spec, you're getting this for free.

[00:00:33] And so I added some additional things, debug element. I showed you how to grab a service, or actually override a service. And then use debug injector git to actually pull that back out. But most of the work has already been done for you. Where you're gonna run into problems is that typically you're not satisfying a dependency on your component.

[00:00:58] And so when we were setting up for this module, what I had to do is I had to go and actually add in these two dependencies as well as all of this, and then it worked. So if you have a test and you're not running it constantly and you add in some additional dependency, you have to update your test to reflect that.

[00:01:21]
>> Speaker 2: Do you ever recommend [COUGH] using the NO_ERRORS_SCHEMA for testing?
>> Lukas Ruebbelke: I haven't. There may be a good case, but typically something's wrong, I wanna know about it. Now if it's not providing, in other words, it's an odd configuration thing that actually is not affecting my test, I have seen where we've turned it off for that reason.

[00:01:47] But typically when you write things, it's very fine grained, so you have to be careful that if you have a problem in your code that a lot of times what people see as a problem is really a trailing indicator that something else is wrong. So when somebody says this component is really hard to test, so we have a problem testing, well, no, your on init is 250 lines long and you're doing 17 different things.

[00:02:20] What exactly are you wanting to test here? And so when people say, testing is hard, well, testing, untestable code is sometimes nearly impossible. Also by moving a lot of the component logic and the different things that typically lived in the components we saw, or if you looked at NGRX, and how you move that into producers and stores and those different things.

[00:02:48] That a lot of the problems tend to just work themselves out. In terms of everything is in one place, it eliminates like race conditions or what data do we use.
>> Speaker 3: In broad strokes, how can we test our store reducer selector and effects?
>> Lukas Ruebbelke: So I would, well,

[00:03:12]
>> Lukas Ruebbelke: In broad strokes, so we don't have, in this particular repo, we don't have an implementation of NGRX. But what I can tell you is that full reducers, those are very easy to test because what you have is when I called this reducer, something comes in, something comes out.

[00:03:36] And so these are typically very small tests, in, out. And even with selectors, those are also pretty easy to test. Is that, I'm going to call this selector and I expect this thing to come out. Now where testing gets difficult, and I can provide some additional information on that in maybe like a resource section, is effects can be tricky because of the observables.

[00:04:12] And so this is where if you're testing observables, then you have to understand like jasmine marbles, and so that's kind of an additional thing that you kind of wrap your mind around. But again, by moving everything into your store and your reducers and your selectors, well, now everything is kind of very fine grained, simple purpose, easy to test.

[00:04:37] And if something is what I would say is a pure function with a clean contract, you put something in, you get something out. Those are easy to test. Where it gets tricky is, I expect when something comes in, for certain things to happen in a certain order. And then, now you're having to verify that flow of control.

[00:05:01] But I can provide an additional link. So if you actually look at my repo or repos or getup.com or a hungry mind, and there is like an NGRX quick start that you can look as well as an NGRX workshop. Are we going there that will have a lot of tests specifically to NGRX.