In this lecture, we are going to prepare our app for testing before getting started.
You should launch the test runner with the NPM run test command for the rest of this section.
You should always have this command running.
We are going to be writing a few tests with Karma and Jasmine.
Once the server is running, let's inspect the console for errors.
Dozens of errors will appear in the console.
The question is why?
The reason is simple.
During the development of our application, test, files were generated for each component service pipe
and class.
A test file can be identified by its extension, which is spec tests.
Throughout most of this course, we've ignored these files.
The test command will scan our project files with these extensions.
If a file has this extension, the test will be loaded with our application in the browser.
Angular recommends defining test files with their relative classes.
For example, if you're writing a test for the app component, the test for this component should be
placed in the same directory as the component scattered through our project are test files.
Initially, Angular will prepare your test files.
For example, let's look at the app dot component dot spec dot test file.
Dozens of lines of code are written inside this file.
Angular will create initial tests for your classes.
Here in lies the problem.
The tests are designed to pass for the original copy of the component.
Since the beginning we've performed dozens of changes to the app component.
Therefore, the tests will fail.
This goes for the other tests as well.
All tests are broken for this section.
We are going to start with a clean slate on the sidebar.
Open the project with the file Explorer.
Inside the search field.
Search for files with the suspects extension.
The Explorer will present us with a complete list of our test files.
You have two options at your disposal.
You can delete all test files.
Alternatively, you can rename the test files.
I prefer to rename the test files.
We'll be able to revisit the test files in future lectures.
Let's rename the files by changing the extension from spec to spec broken tests.
I'm going to perform this renaming for each test file.
Great.
The test runner will ignore every test file.
We are starting with a fresh slate.
It'll be easy to identify which tests are broken by their file name.
In the next lecture, let's begin writing our first test.