{ "id": "guide/testing", "title": "Testing", "contents": "\n\n\n
Testing your Angular application helps you check that your app is working as you expect.
\nBefore writing tests for your Angular app, you should have a basic understanding of the following concepts:
\nThe testing documentation offers tips and techniques for unit and integration testing Angular applications through a sample application created with the Angular CLI.\nThis sample application is much like the one in the Tour of Heroes tutorial.
\n For the sample app that the testing guides describe, see the
For the tests features in the testing guides, see
The Angular CLI downloads and installs everything you need to test an Angular application with the Jasmine test framework.
\nThe project you create with the CLI is immediately ready to test.\nJust run the ng test
CLI command:
The ng test
command builds the app in watch mode,\nand launches the Karma test runner.
The console output looks a bit like this:
\nThe last line of the log is the most important.\nIt shows that Karma ran three tests that all passed.
\nA Chrome browser also opens and displays the test output in the \"Jasmine HTML Reporter\" like this.
\nMost people find this browser output easier to read than the console log.\nYou can click on a test row to re-run just that test or click on a description to re-run the tests in the selected test group (\"test suite\").
\nMeanwhile, the ng test
command is watching for changes.
To see this in action, make a small change to app.component.ts
and save.\nThe tests run again, the browser refreshes, and the new test results appear.
The CLI takes care of Jasmine and Karma configuration for you.
\nYou can fine-tune many options by editing the karma.conf.js
in the root folder of the project and\nthe test.ts
files in the src/
folder.
The karma.conf.js
file is a partial Karma configuration file.\nThe CLI constructs the full runtime configuration in memory, based on application structure specified in the angular.json
file, supplemented by karma.conf.js
.
Search the web for more details about Jasmine and Karma configuration.
\nYou can also unit test an Angular app with other testing libraries and test runners.\nEach library and runner has its own distinctive installation procedures, configuration, and syntax.
\nSearch the web to learn more.
\nLook inside the src/app
folder.
The CLI generated a test file for the AppComponent
named app.component.spec.ts
.
The test file extension must be .spec.ts
so that tooling can identify it as a file with tests (AKA, a spec file).
The app.component.ts
and app.component.spec.ts
files are siblings in the same folder.\nThe root file names (app.component
) are the same for both files.
Adopt these two conventions in your own projects for every kind of test file.
\n\nIt's a good idea to put unit test spec files in the same folder\nas the application source code files that they test:
\nApplication integration specs can test the interactions of multiple parts\nspread across folders and modules.\nThey don't really belong to any part in particular, so they don't have a\nnatural home next to any one file.
\nIt's often better to create an appropriate folder for them in the tests
directory.
Of course specs that test the test helpers belong in the test
folder,\nnext to their corresponding helper files.
One of the best ways to keep your project bug-free is through a test suite, but it's easy to forget to run tests all the time.\nContinuous integration (CI) servers let you set up your project repository so that your tests run on every commit and pull request.
\nThere are paid CI services like Circle CI and Travis CI, and you can also host your own for free using Jenkins and others.\nAlthough Circle CI and Travis CI are paid services, they are provided free for open source projects.\nYou can create a public project on GitHub and add these services without paying.\nContributions to the Angular repo are automatically run through a whole suite of Circle CI tests.
\nThis article explains how to configure your project to run Circle CI and Travis CI, and also update your test configuration to be able to run tests in the Chrome browser in either environment.
\nStep 1: Create a folder called .circleci
at the project root.
Step 2: In the new folder, create a file called config.yml
with the following content:
This configuration caches node_modules/
and uses npm run
to run CLI commands, because @angular/cli
is not installed globally.\nThe double dash (--
) is needed to pass arguments into the npm
script.
Step 3: Commit your changes and push them to your repository.
\nStep 4: Sign up for Circle CI and add your project.\nYour project should start building.
\nStep 1: Create a file called .travis.yml
at the project root, with the following content:
This does the same things as the CircleCI configuration, except that Travis doesn't come with Chrome, so use Chromium instead.
\nStep 2: Commit your changes and push them to your repository.
\nStep 3: Sign up for Travis CI and add your project.\nYou'll need to push a new commit to trigger a build.
\nStep 1: Create a file called .gitlab-ci.yml
at the project root, with the following content:
This configuration caches node_modules/
in the install
job and re-uses the cached node_modules/
in the test
job.
Step 2: Sign up for GitLab CI and add your project.\nYou'll need to push a new commit to trigger a build.
\nStep 3: Commit your changes and push them to your repository.
\nWhen the CLI commands ng test
and ng e2e
are generally running the CI tests in your environment, you might still need to adjust your configuration to run the Chrome browser tests.
There are configuration files for both the Karma JavaScript test runner\nand Protractor end-to-end testing tool,\nwhich you must adjust to start Chrome without sandboxing.
\nWe'll be using Headless Chrome in these examples.
\nkarma.conf.js
, add a custom launcher called ChromeHeadlessCI below browsers:protractor-ci.conf.js
. This new file extends the original protractor.conf.js
.Now you can run the following commands to use the --no-sandbox
flag:
Note: Right now, you'll also want to include the --disable-gpu
flag if you're running on Windows. See crbug.com/737678.
After you've set up your app for testing, you may find the following testing guides useful.
\n