This week we want to continue our series about Angular 2 by looking at the Unit Testing capabilities that Angular 2 provides for us. What we want to cover today is:
- Tweaking Karma to avoid using the Browser Window
- Code Coverage
- Tips to testing components
This article was written using Angular CLI version 1.0.0-beta.20-4 (Tip, if you are upgrading on windows, rm –rf node_modules dist temp just means to delete the three directories. You can do that part manually, or install bash for Windows and run the command in bash.)
Tweaking Karma
Open up the project we’ve been working on.
Drop into command line mode and run ng test The first thing you will notice is that this brings up the Chrome browser to run your test. I don’t know about you, but I really dislike having a browser window up. I have enough windows running on my screen as it is. This is the first thing we need to fix. To do this we are going to install PhantomJS.
npm install --save-dev phantomjs-prebuilt
Then, we need to tell karma to use PhantomJS. This is a two step process. First, we install the karma phantomjs runner npm install --save-dev karma-phantomjs-launcher Next, we modify the karma.conf.js file Change require('karma-chrome-launcher'), and browsers: ['Chrome'], To require('karma-phantomjs-launcher'), and browsers: ['PhantomJS'], Last, since we are not using the browser, we will need a better reporting mechanism.
To do this we will install spec reporter.
npm install --save-dev karma-spec-reporter
and we replace this line in karma.conf.js
1 | reporters: config.angularCli && config.angularCli.codeCoverage |
with
1 | reporters: config.angularCli && config.angularCli.codeCoverage |
And we add a require line at the top of the file with the other requires
require('karma-spec-reporter'),
Now, when we run ng test We get a nice text report in our terminal windows instead of the browser popping up.
Code Coverage
To get a code coverage report for our test use the command ng test –cc The code coverage files will end up in a directory named ‘coverage’ hanging off the root of your project. You can view the coverage/index.html file to see how well your files are covered.
Testing Components
For the purposes of this article, I’m going to assume you have some familiarity with creating Jasmine tests. If you don’t the documentation for Jasmine is pretty easy to understand.
But what I do want to cover here is how we test components.
If you open up the app.component.spec.ts file, you’ll notice a TestBed class that gets used quite a bit. Since your test isn’t going to test modules because they only package our other code together, you need some way of faking that out so you can test the components. To do that, you use
1 | TestBed.configureTestingModule( { declarations: [ AppComponent ] }); |
Which just sets up the declarations you need to reference the component you need to test. You can put anything in this block that you would normally put in your module definition.
Another TestBed method you’ll see is
1 | TestBed.createComponent() |
which you probably have guessed, creates an instance of the module so you can test it. The object it creates has a debugElement property hanging off of it. There are two properties that hang off this object that you’ll make use of a lot. componentInstance is the actual instance of the component that you created. Any properties and methods that your component has will be available off of componentInstance.
The other object that will be available is nativeElement. This is the DOM element that the component renders to and you can use querySelector(cssSelectorGoesHere) to select the first element matches the selector or querySelectorAll(cssSelectorGoesHere) to retrieve an array of elements that match.
Of course, a test isn’t any good if you don’t make changes to the component and test for them. And for that we have detectChanges(). You’ll see that being used in the third test. You’ll want to use that before you expect() anything.
Ready, Set, …
Now that we have some way of testing our code, we can actually begin to write so. Don’t forget to subscribe to the email I sent out so you don’t miss the next article in this series.
Code so far is located at https://github.com/DaveMBush/GettingStartedWithAngular2/tree/Step2