Exercise (Video): Angular Testing

Loading...

From the course by The Hong Kong University of Science and Technology

Front-End JavaScript Frameworks: Angular

464 оценки

The Hong Kong University of Science and Technology

Front-End JavaScript Frameworks: Angular

464 оценки

Course 2 of 5 in the Specialization Full Stack Web and Multiplatform Mobile App Development

This course concentrates mainly on Javascript based front-end frameworks, and in particular the Angular framework (Currently Ver. 4.x). This course will use Typescript for developing Angular application. Typescript features will be introduced in the context of Angular as part of the exercises. You will also get an introduction to the use of Angular Material and Angular Flex-Layout for responsive UI design. You will be introduced to various aspects of Angular including components, directives and services. You will learn about data binding, Angular router and its use for developing single-page applications. You will also learn about designing both template-driven forms and reactive forms. A quick introduction to Observables, reactive programming and RxJS in the context of Angular is included. You will then learn about Angular support for client-server communication and the use of REST API on the server side. You will use Restangular for communicating with a server supporting the REST API. A quick tour through Angular animation support and Angular testing rounds off the course. You must have either completed the previous course in the specialization on Bootstrap 4, or have a working knowledge of front end web-UI frameworks to be able to navigate this course. Also a good working knowledge of JavaScript, especially ES 5 is strongly recommended. At the end of this course you will: - Be familiar with client-side Javascript frameworks and the Angular framework - Be able to implement single page applications in Angular - Be able to use various Angular features including directives, components and services - Be able to implement a functional front-end web application using Angular - Be able to use Angular Material and Angular Flex-Layout for designing responsive Angular applications - Be able to use Observables and RxJS in the context of Angular applications

From the lesson

Client-Server Communication

In this module you will explore client-server communication using both Angular HTTP module and the REST API. You will get a brief introduction to animation support in Angular and create a custom attribute directive. You will also learn about testing, building and deploying Angular applications.

Angular Testing13:53

Exercise (Video): Angular Testing49:44

End-to-End Testing Angular Applications7:32

Exercise (Video): End-to-End Testing Angular Applications25:52

Meet the Instructors

Jogesh K. Muppala
Associate Professor
Department of Computer Science and Engineering

[MUSIC]

The fragrance of Jasmine from all those flower gardens

on the Temple Street wafting through the air,

what a setting feeling, must be the good karma from my past life.

Sorry, where was I?

I was talking to you about Angular Testing, right?

We we're going to use karma and

Jasmine to do our Angular Testing, so let's get on with it.

One good thing about using the Angular CLI is that it sets up all the scaffolding for

you to automatically include the support for testing your angular application.

So you would notice that whenever you generate a component or

a service, along with the component TS files,

you will also notice a file called component.spec.ts

already included into your project folders.

And also, if you go to the package.json file, you will see that there

is all ready support for the angular testing included there.

So if you're going to the dev dependencies you will see that the Jasmine code,

the jasmine spectra ported the karma and karma related

MPM modules are already installed within

your Angular application that is scaffolded out by Angular CLI.

So we have all the things in place for

us to just get on with doing our testing for our Angular application.

So if you look around, you will see that there is a file called test.ts

in your source folder, so let's open the test.ts file.

You'll also see that there is another folder there called e2e,

we will come back to that in the next exercise.

But in the test.ts folder,

you will see that this is where your karma support is being configured here.

So going into this test.ts file, by default,

when you use the Angular CLI support for test, it will run the tests for

all that components and

services that are included in your Angular application.

Now, I am going to illustrate to you how to do testing for

one specific menu component.

So I want to restrict myself to only use the menuComponent.spec file and

do the testing for just the menuComponent.

So, go into the test.ts file,

one way we can configure where Angular CLI's test,

to run the test only for a specific component,

is to go to this line here which says const context.

And then change this to menu, you can see /menu and

\.component and spec.ts file, so

earlier it was just / and \ .spec.ts file,

which means that it will run all the spec files

that are there in your project source folder.

So right now by specifying this here, I am requesting

it to run the test only for the menu component, spec file here.

Now this I figured out by searching around on

stack overflow where I found somebody giving me the answer to this

pointing to some resource on Angular CLI.

And so that's how I figure out that this is the way to restrict

the test to a specific component's test file.

So after making the change to the test.ex file, let's save the change,

now we will try to run our test on the many components.

So as you see in the menu component,

we already have the menucomponent.spec.ts file which contains some code already.

Let's try to run this test and see what happens, going to the terminal,

at the prompt, type ng test.

And this will result in an Angular CLI starting the testing for

the menu component So when you type this and

hit the Return, then AngularCLI will start compiling your Angular application.

It'll also open a browser window, in my case it'll open a Chrome browser window.

And then use that browser window to run the test, and you'll see that in the back

you have the current browser window running, and

it is all full of red and a whole bunch of words there.

The same information will also be printed out in your console window,

and from this, I can see that my test did not run correctly.

There was something not configured properly in my test file, so

I need to go and edit my test file to include

appropriate support for running this test correctly.

So let's go to the menu component spec.ts file and

then prepare our test accordingly.

Now we can leave the engine test running right here,

any time you make changes to the menucomponent.ts file or

the menucomponent.spec.ts file and

save the changes, this test will automatically run at that point.

So, let's go to the menucomponent.spec.testfile,

we understand that the spec file uses that

Jasmine syntax for describing the test.

So you already notice that there is something

here which starts out with describe and then there is a function defined in there.

So this is what I was referring to when I talked about the Jasmine syntax earlier,

and also if you scroll down you will see an it also in there.

And in addition, you will see something called beforeEach here, let's

examine the style in a bit more detail to understand how the file is configured and

how this test is set up in this particular file.

So within this tested file, you will notice that we are importing here

a set of classes from angular/core/testing.

So this module enables you to provide the testing support for

your Angular application and enables you to design the test for your component.

So you see that I am importing async and ComponentFixture and

TestBed from this testing library angular core testing library,

also you'll see that the MenuComponent is also important here.

Now, once we understand these two

let's walk down the code to understand what we are trying to do here, so

here as you expect this describe here is specifying that.

This particular function is describing a Jasmine based test

that we are specifying for our Angular application.

So when you look at the describe here you will see that this

includes all this code in here.

So this is part of one single set of tests that we're running on our MenuComponent.

So inside the describe you will see that there is a string here,

this specifies this particular set of tests that you're running here.

So it says on the MenuComponent, so here you can specify whatever string you want.

You can use this as a description to specify what this

particular set of tests are doing.

So here,

I'm going to stay with the default saying we're trying to test the MenuComponent.

And after that, you'll see that we are specifying an arrow function here.

Within this arrow function,

we are going to construct the test for our MenuComponent here.

So after this, you see that we are declaring

a variable component which is of the type MenuComponent.

And then, we are also declaring a fixture variable,

which is of the type ComponentFixture, which is off the type MenuComponent.

Now, why is this interesting?

Now, within our Angular application,

we have the MenuComponent that we have already designed.

So, in this test file,

we're going to create that MenuComponent using the Angular TestBed.

And then, we're going to carry out the tests on the MenuComponent.

So we're going to isolate the MenuComponent, and

then carry out UnitTests on that specific component.

Now, this is where the Angular testing utilities,

which come with the support using TestBed.

The TestBed allows me to set up the environment

within which I can test my Angular component.

So here, you see that we are saying TestBed and

then calling the configureTestingModule method of the TestBed class here.

And inside this configureTestingModule you can declare a bunch of things,

and you will see me adding more here.

This acts exactly like the ngModule configuration that you do for

our app module there.

So all the information that you need for

setting up the MenuComponent will be declared here.

So the ngModule part that you saw in the app module,

similar kind of syntax can be used here to

declare the support for testing the MenuComponent here.

And also, after this, you will see this function called to compileComponents.

So this method will compile the MenuComponent and

make it ready for during the testing.

Note also that this whole thing, this function here

is enclosed inside something called an async here.

Now why do we need this async?

Now, because the preparation of the components

using this compileComponents method takes some amount of time.

And until this is completed, we can't proceed forward with the tests.

So using the async module, we are essentially specifying that I'm

going to wait for this whole thing to complete before proceeding forward.

So the async module, as you see,

wraps a test function inside an asynchronous test zone.

So what this means is that this test will automatically complete when all

the asynchronous calls inside this zone are done.

So this is what the use of the async that we have here does.

So what this means is that you can use this async function

either in the beforeEach or in the it also.

So within the it declaration, so when you see written the it, also,

you will see that you can use the async.

So in case you have any operations here that are done asynchronously, then you

need to wait further up those operations to complete for that test to complete.

So for example, if you're calling a service and wait for the service to

return the value then, all that needs to complete before you can proceed forward.

So those are enabled by using this async to surround this function here.

Now, in addition, the second beforeEach, now, we have separated this

into two separate beforeEach here, because we want this to complete.

And this compileComponents is going to take a certain amount of time.

Especially, if your component is using an external template,

as we do in our MenuComponent.

So it requires some time for the external template to get ready for

my testing to proceed forward.

So, we need to wait for this whole thing to complete.

So that is why, after this is complete, then,

we will get to this second part where we are going to get

some references to some values from the test back.

Now, what is this beforeEach function that you are doing here?

What the beforeEach means is that whatever you declare inside here,

that function will be executed before each test

that you're going to specify later on using the it.

So using this beforeEach, you can set up the initial

configuration for your test to proceed forward.

So meaning, that here, we are setting up our TestBed,

preparing our MenuComponent, and then, setting up a few things for

our MenuComponent before we proceed on to carry out the test.

So for each of the tests that you're going to specify using an it here,

this beforeEach, whatever you specify in this beforeEach will be

executed before the test is conducted.

So here, as you can see, I am preparing the TestBed.

Thereafter, I am getting access to the fixture.

So I am using the TestBed and saying, createComponent and menuComponent.

So this will return me a reference to the menuComponent that I'm

creating within my test script here, and then get a reference to that.

Because I will need a reference to that in order to do some

manipulations on the component there.

In addition, from the fixture, I am getting an access to

the componentInstance that is being created by my ComponentFixtures here.

So as you can see, the ComponentFixture of the type MenuComponent, and

then calling the componentInstance gives me access to the specific MenuComponent

that I have created inside this TestBed for carrying out the UnitTests.

Now, after this, we call this method called fixture.detectChanges.

Now what this means is that this will proceed forward only after all the changes

are completed and then recognize that the changes are completed.

So this will trigger a change detection cycle for this component.

So what this means is that this will ensure that if you have made any changes

earlier, all the changes are detected and

everything is stabilized before you can proceed forward with your test.

Now after this, we are going to use our it to configure our first test here.

What is the first test that we are doing here?

The first test, what we're going to test is,

to make sure that the component has been created.

So within this here, I am using the Jasmine's syntax and here I'm saying, it.

And then here, you can give a description in the form of a string to specify,

what this test is actually testing about?

So, what we are saying is,

we are testing to see if the component has been created or not.

So to do that, I'm saying it should create,

meaning that, this setup here should have created the component correctly.

So that's why inside here, I'm using this method called expect.

So the expect method inside here takes a value here, and

then you can test to see if this value satisfies something.

So here, we are saying to beTruthy,

meaning that, this particular value should be true.

That is what specified by this method call here call toBeTruthy.

You can also say toBeFalsy, meaning that, that should evaluate the false.

But in this case, we are testing to make sure that the component has been cleared

correctly, so that's why we are saying, expect toBeTruthy here.

So this is a simple test that we are doing to make sure that

our component is currently getting created.

But as we realize when we run this test, it is not running correctly.

Let's quickly glance and see what the problem is within our component,

the creation in the console window there.

Going back to the console window, let me just browse back and

see where the problem is.

And I'm beginning to notice that, this is specifying that it

doesn't seem to be recognizing some of the things that my component is using.

In specific, in particular it is saying that,

the md-spinner is something that it doesn't recognize the md-grid layers and

a few other things.

But immediately suggests to me that I need to do a few more

configurations within my test file before my test can run correctly.

So, let's go back to our spec file and make some changes to it.

Going back to our spec file.

From our Recollection of how we created the template.

We know that within the template,

we have a router link in the menu components template.

So, I need support for routing in order to recognize

that router link that we used within the menu component .HTML file.

So, this is where I'm going to import

another test support provided called

as the RouterTestingModule which is available

from angular/router/testing library here.

So this router testing module will enable me to configure some aspects

about my router.

We will see that the way we use, this is a little different from the router module

that we have used in our applications.

So we'll import the router testing module.

Also, you note that we are using some animations and

also, using the Angular material component within our template.

So I need to import

the BrowserAnimationsModule into my test file.

So this comes from angular/platform-browser.

Now you'll notice that, we need to do this explicitly here simply because,

in the actual Angular application, all these was in the Ng module,

the app module, and so, that was available for all the components.

Right now, we are testing this component, the Menu Component, in isolation, so

that's why it doesn't know about all these things, so

we need to explicitly specify all these things here.

So, I will import that from platform browser animations here.

So angular platform browser animations,

I'm Importing the browser animations module here.

Now in addition, I know that I'm using the material module,

so I'm going to import the MaterialModule from

angular material, because with all of that,

my template where I am using the support from angular material,

all those things will not be recognized by my,

Testing Pipe, so

let me include MaterialModule and also the FlexLayoutModule.

So I will include angular/flex-layout, so

these two are needed because I need them in the template.

I'm going to also import the Dish from

shared/dish, because as you will see later, I

need to configure a Dish service,

Because my menu component depends

upon the, dish service.

So I need that also in place.

Although you would see that, I am going to stub that out.

I'll explain that in a short while.

And also I need to import a few more things.

I will important DISHES from you recall that we use this constant called dishes

That we exported from the shared dishes.ts file.

I will need that in order to configure a few more things.

I'm also going to import the baseURL

Which I declared in the shared/base,

Url file, and also,

I need to import the Observable.

From rxjs/.

Because I will also be using the observable a little bit later when I can

figure a few things.

So now, I have imported all of these things.

Getting down in the TestBed configuration, you see that this part

is exactly like the NG module decorator that we have in the app module.

So, this is where, I can also use the imports,

just like I did with theNG module.

And within the imports, I am going to import the BrowserAnimationsModule,

because that is something that I require.

And then also import the MaterialModule and

the FlexLayoutModule,

and also the RouterTestingModule

because I would need the RouterTestingModule to configure a.

Now when you use the RouterTestingModule you need to use this method called

withRoutes instead of using forRoute as we used for the router module here.

So within this withRoutes you can specify some default

routes that you need, for your specific application here.

I'm just going to configure only one single path here and

that is good enough for me for testing this module here.

So I'm just going to say {path: 'menu',

component: MenuComponent}.

And that is all that I need for

this particular imports to be configured here.

So along with the imports we have the declarations where I have

the MenuComponent being used here.

I can also configure the providers here, so I need to configure the providers here.

Now this is where we're going to create a few stubs here.

So I will say {provide: DishService}.

Now, the DishService that we are going to use here is not going to be the real

DishService.

When you are testing a component you don't want to use the real service,

instead you'll be stubbing out the service and then use a stub

DishService which I'm going to call as dishServiceStub.

So I will say useValue dishServiceStub,

so this would be a stub function that I will

use in order to mock the DishService here.

So that is one that I am going to make use of.

And also the second one that I'm going to make use of is,

BaseURL.

Which I'm going to useValue as the baseURL that we have already imported earlier.

So now with this, I have actually configured my TestingModule.

So notice that the way we specified this is exactly like the way we

specify the ngModule decorator for our app module.

And here we are only configuring those that are required by the menu component.

So I don't have the other ones that we use in the app module itself.

So this is how we will configure the TestingModule.

Now, the one thing missing is this dishServiceStub.

So what I am going to do is to implement a function here and

call that let dichServiceStub be.

A simple JavaScript object here,

which I'm going to let it act

in place of the real service.

We can stub out services like this as seen here.

So inside here, I'm just going to supply a simple function,

the getDishes function here,

which will return Observable<Dish[]>.

So that is exactly how the return value was configured there,

and I'm going to return an Observable.of(DISHES) here.

So using the stub function here,

what I am doing is I am stubbing out the DishService and

then configuring it with this one method that I need for my test.

Saying getDishes and then when this method is called,

I'm just going to return this value, the DISHES constant here.

So this way now you can see that how I am controlling what is being supplied

to the component from a stub DishService that I've just created here.

So this is how you will create stubs for your DishService.

The other approach that we can use for

cases where we are using services is call as using this spy.

Jasmine supports something called Spy which allows us to spy on function

calls and then capture the function calls and then respond to those function calls.

So that is another way of using a fake service in place of the real service.

So now we are able to control what is being supplied to our menu component.

So after these modifications then we're

going to go down into before each method.

After the what I am going to do is I will get

hold of the dishService.

So you see that I am using the TestBed.

And then using the get method of the TestBed to get hold of

the DishService that has been created here

from this particular stub that we have declared here in the providers.

So this gives me a reference to the dishService so

that I can call the methods of the dishService wherever I need here.

So after making these changes, let's save the changes and then see how our

angular CLI will run this test after all these changes and

whether our test will be successful at this point or not.

So let's save the changes.

The moment you save the changes you will notice that

your ngtest will start rerunning our test again.

So it will compile the application and then read on the test and [SOUND].

Our test successfully passed after making the changes

to our menucomponent.spec.testfile.

So our first test, meaning that we are now able to create a menu

component from our menucomponentspec.testfile.

So our test set up is working right.

Now I can go in those more intense tests within my test component.

Going back to the menu component's spec file, let me add in another test.

Now you see that because I now have a stub dishService

here which is returning this DISHES value,

I can then now make use of my dishService

to which I have guard the reference in here inside this before each And

then call the getDishes method and then I'll be able to obtain the value,

and that will be available within my MenuComponent that I have just created.

So my menu component should now get access to the dishes

constant that has been supplied back through this DishService step.

So I can now test to see if the dishes variable

inside my MenuComponent is actually receiving the values correctly or not.

So going in let me create another test here.

So I will create a test here with the it

as you saw earlier, so just like the previous one.

This second test I'm going to call that as it and

dishes items should be 4, because their

dishes constant that we declare in the share.dishes

file has four dishes in the constant.

So when my dishes variable inside my MenuComponent.ts file

gets initialized by calling the DishService it should have

received those four dishes and got initialized with those four dishes.

So I'm going to carry out a few tests on the dishes variable there.

So how do I get access to the dishes variable here?

So I would say it('dishes items should be 4',.

And then I will declare an arrow function here.

And inside this arrow function I'm going to specify

the radius test that I am going to carry out.

So here, I am going to now say expect(component.),

and notice that it automatically gives me access

to this dishes property from the MenuComponent.

So I could say component.dishes.

And then I can test to see that the length of that

dishes JavaScript object array should be.

So this is where I use the Jasmine's toBe method here and

then I can specify a value 4 because I was supplying four dishes

in my dishes constant that I have declared in the shared or dishes file there.

So that is the first test that I'm going to carry out.

This should turn out to be true, otherwise the setup did not work correctly,

so I know that my code is not working correctly.

But I know for sure that this test should work out correctly.

If you want to be sure, let's save the changes and

then go and see our test running.

Go into the terminal, you see that now my app is being recompiled and the test runs.

And notice all the greens in the terminal window,

it says Executed 1 or 2 SUCCESS, Executed 2 of 2 SUCCESS.

So which means that both my test ran successfully.

If I look at my browser, so

you see that the MenuComponent both the tests are successful.

Let me create a few more and

add them to the set of second group of tests that I'm creating there.

Going to the many component spec.ts file.

I will add in

one more.

I will say expect(component.dishes[1].).

Recall that the first dishes name was, so

that is what I'm going to test, dishes[1].name.

So this is how I can test to see if it is receiving values correctly.

What are all the ways that I can test if I put a dot there,

it will give me a suggestion of all the possibilities here.

So I will say, I will also again use the toBe

method here and then the second dish name is,

Just that there, so that is the second test that I'm going to carry on.

So if my code ran correctly then this should also pass.

Similarly, let me put in one more here.

And so I'll say expect.

Component.dishes, and I will say three.

And in here the featured property should be Falsy.

That should be false, is not true in this case.

So let me add in one more.

You can start adding more if you want,

play around with it until you are satisfied.

So, do those additions.

Let me save the changes that I have made here.

Let's go and see if this test runs correctly.

I am going back to my terminal.

You'll see that my test is again running.

You'll see that both the tests were successful.

Now I'm going to make one of those things fail.

So I'm going to go in and change this to Truthy.

See that is the fun of playing around with code.

I'm going to change this to Truthy, and I know that this test is going to fail.

So let's save the changes.

Taking a look at the terminal, you'll see that the test is again running.

And when the test runs.

There you see.

The test has failed.

You see all of those red here.

So meaning that the second test did not pass correctly.

And if you scroll backwards you will see this particular

test failed because somewhere down there it'll

say that it did not- okay, see this statement here,

it says expected false to be truthy.

So that's why it failed, so it is not supposed to be true but

I said it should be true.

And obviously that test is wrong, so that's why the test failed.

So this is how you can even test to see if, but

if the test fails, if you ask for the wrong things, also.

But, again, let me go back and correct that one more time.

So, going back to my file,

I'll change that back to Falsy, because I want this test to run correctly.

Now, we are not satisfied yet.

Now in this particular test, I'm only testing

the dishes variable that is inside my MenuComponent.

How do I go about playing around with the template itself?

So, this is where we need some more help from Angular.

To carry out some tests on the template I'm going to go in and

pull in a couple of more imports here.

So going to my top of this file,

MenuComponent spec.ts file, I'm going to import.

One more called By, which is a method You will see me using this in a short while.

This should be imported from

Angular Platform browser.

And also I'm going to import one more, which is a DebugElement.

The DebugElement allows me to get access to the DOM so

that I can carry out tests on the DOM elements directly.

So that's where I'm going to import dash from the angular core here.

So this two, so add in the by and the DebugElement to the imports.

And then, once you do that, we'll walk down into the code here, and

then we will add in one more test where we are going to go into the DOM and

then fetch one of the items from the DOM.

So, I would say it, so one more test here, what is this test going to do?

For this test, I will specify the test as

should use dishes in the template.

I'm just randomly saying something here because I just want to check to see

that the dishes variable,

whatever it is making available is being used in the template correctly.

So that's the part that I'm setting up.

And then the second part is the arrow function.

And within this arrow function,

I'm going to supply the code for the next test.

So inside this arrow function,

what I'm going to do is I will first call

fixture and then detectChanges,

and then after that I will say let de,

Is a DebugElement.

Through this I'm going to get access to the DOM.

And then, The element

would be HTMLElement.

So I want to get access to one of the HTMLElements from my doc.

So which element do I want?

So to do that I will get access to the,

DebugElement by saying fixture and debugElement.

So this allows me to get access to items from my DOM here.

So debugElement and then I can query and

pick only those that will be of interest to me.

So I'm going to query, and then I will ask for by using the by.

So notice where I am using the by that I have included, by importing it.

So By, the By supports a bunch of methods by which I can

ask to access particular elements in debug.

So as you can see, it will tell me what I can import and

then the .css allows me to get access to

Match elements by the given CSS selector.

So what is the CSS selector that I am going to use?

I know that there is an HTMLElement in the DOM and

I'm going to get access to the first H1 element from the DOM.

And one of the h1 elements in there is the one that is going to

display the name of each dish there.

Look back and you see that inside the grid tile line using an h1 and

that h1 contains the name of the dish there.

So I'm going to get a hold of that, and then I'm going to get an element and

then I would say de from debugElement.

And then I would say nativeElement, and

that gives me access to the element specifically in the DOM.

That I am referring to and I have selected by using this statement earlier.

So when I query the DOM, and then say return me all

those which are using the tag h1 for the HTML element.

And I get access to that and then I can query and

say expect el.textContent.

So I'm looking for the content inside this h1 in my

template textContent and then I will say toContain.

So this is another method toContain this is adjustment method called toContain.

Checks to see if that contains a particular value and

then I would check for DISHES 0.name.

So, is the first Dish been created in the DOM and added into the DOM.

If my template works correctly, then that must be present in the DOM.

So that is what I'm going to check, to see if the grid tile correspondent

to the first DISH has been created and added into the DOM or not.

So I'll say DISHES 0.name and say toUpperCase.

Recall that I used the UpperCase pipe

to display the name of the DISH by converting the name of the DISH into

all uppercase in the grid tile in the menu component.

So that is what I'm going to check for, okay?

So I'm just checking for only one of them.

You can carry out many of those tests.

You can check for dishes1.name and then dishes2.name and more if you want.

I'm just illustrating one example of how you would access elements in the DOM and

then check what they contain inside there.

So this is one test that I'm going to conduct here.

So let me save the changes and then see if the test runs correctly.

Going to that terminal we will see that my test is now being recompiled.

And when the test runs, you see that my first test was successful,

the second test was successful, and the third test was also successful, wonderful.

Now, let me make that third test fail.

Going back to the menucomponentspec.ts file

I'm going to remove this toUpperCase, and then carry out the same test.

You will see that this test will fail.

Save the changes, and

when the test runs, you will see that the third test will fail.

Because I am causing it to fail by checking for the wrong thing there.

And there you go.

The third test failed here.

So, this is how you can check to see whether certain things that

are suppose to be there are there correctly, or not.

Why is this the case?

So, you can see, here, the reason why this test failed.

It is expecting this to be in the DOM, but

instead this is what is in the DOM, in the H1 element in the DOM.

So that's the reason why the test failed here.

So again, going back, let me correct that mistake.

And then when I rerun the test, you should now see that the test passes successfully.

Now going back to the terminal, you will see that when the test runs now,

it'll run correctly.

And there you go, all the three tests are passed by my application.

Also, looking at the browser you can see that the three

texts successfully were executed on the mini components.

A template file and also the mini component itself.

Now, obviously this is not necessarily the most comprehensive test.

But I just wanted to give you a flavor of how you would go about constructing

tests within your angular application.

If you get carried away, you can go into all the TS files that you have,

and then write your own tests for each and

every one of those components using the knowledge that you have gained here.

Also, you can read more about casting in the angular documentation and

to learn more ways of carrying out tests in on your angular repetition.

Testing is a field by itself.

So, if I need to teach you everything about testing that will

become an entire course in itself for angular.

And in this course, I just wanted to give you a flavor of how

you will carry out testing in your angular placation.

And this is an example of how we can configure and carry out a unit test

on one of the components in our angular application.

This is a good time for you to do a good comment with the message components test.

[MUSIC]

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2018 Все права защищены.

Загрузить из App Store

Загрузить в Google Play