Angular Unit Testing Interview Questions
Unit Tests sits at the base of the Testing Pyramid. This means they take lesser time to code and classes that you are testing should be more isolated. For example, a Login Feature normally has Validation and
Authentication logic. They should be written in two separate classes like LoginValidator and LoginAuthenticator. Based on these two classes, you write test scripts.When you try to test Networking functions, like in
LoginAuthenticator, you should use Mock Response to test for both positive and negative responses.Integration Tests sits at the next level after Unit Tests. Here, you will use Real Network Responses, by hitting the real server endpoint, and test that the small units you have written are able to work together.
UI Testing automates repetitive tasks to ensure that your most critical UI interactions keep working as you’re adding new features or refactoring your app’s codebase. It may also help new developers to understand the app as they just need to run the UI Test once, he is able to see the automated test script running the app and interpret the app’s user journey from there.
Going back to the example of a Login Feature, UI Tests will
- 1.Tap on the Username.
- 2.Key in “Username”.
- 3.Tap on Password.
- 4.Key in “******”.
- 5.Tap on Submit.
Here the script will mock a success or failure response to move the app to the next screen, or show an alert box if failed.
Just like how Integration Tests works for Unit Tests, E2E Tests should test the user journeys of the app by using Real Network Response by hitting the Real server endpoints.
a.) Resolving via TestBed
The
TestBed acts as a dummy Angular Module and we can configure it like one including with a set of providers like so:TestBed.configureTestingModule({
providers: [AuthService]
});
We can then ask the
TestBed to resolve a token into a dependency using it’s an internal injector, like so:testBedService = TestBed.get(AuthService);
If most of our test specs need the same dependency mocked the same way we can resolve it once in the
beforeEach function and mock it it there.b.) Resolving via the inject function
it('Service injected via inject(...) and TestBed.get(...) should be the same instance',
inject([AuthService], (injectService: AuthService) => {
expect(injectService).toBe(testBedService);
})
);
The
inject function wraps the test spec function but lets us also inject dependencies using the parent injector in the TestBed.inject(
[token1, token2, token2],
(dep1, dep2, dep3) => { }
)
The first param is an array of tokens we want to resolve dependencies for, the second parameter is a function whose arguments are the resolved dependencies.
Using the
inject function:- Makes it clear what dependencies each spec function uses.
- If each test spec requires different mocks and spys this is a better solution that resolving it once per test suite.
c.) Overriding the components providers
Before we create a component via the
TestBed we can override it’s providers. Lets imagine we have a mock AuthService like so:class MockAuthService extends AuthService {
isAuthenticated() {
return 'Mocked';
}
}
We can override the components providers to use this mocked
AuthService like so.TestBed.overrideComponent(
LoginComponent,
{set: {providers: [{provide: AuthService, useClass: MockAuthService}]}}
);
The syntax is pretty specific, it’s called a
MetaDataOverride and it can have the properties set, add and remove. We use set to completely replace the providers array with the values we’ve set.d.) Resolving via the component injector
When the component is created since it has it’s own injector it will resolve the AuthService itself and not forward the request to it’s parent TestBed injector.
If we wanted to get the same instance of dependency that was passed to the component constructor we need to resolve using the component injector, we can do that through the component fixture like so:
componentService = fixture.debugElement.injector.get(AuthService);
login.component.spec.ts
import { TestBed, ComponentFixture, inject } from '@angular/core/testing';
import { LoginComponent } from './login.component';
import { AuthService } from "./auth.service";
class MockAuthService extends AuthService {
isAuthenticated() {
return 'Mocked';
}
}
describe('Component: Login', () => {
let component: LoginComponent;
let fixture: ComponentFixture<LoginComponent>;
let testBedService: AuthService;
let componentService: AuthService;
beforeEach(() => {
// refine the test module by declaring the test component
TestBed.configureTestingModule({
declarations: [LoginComponent],
providers: [AuthService]
});
// Configure the component with another set of Providers
TestBed.overrideComponent(
LoginComponent,
{ set: { providers: [{ provide: AuthService, useClass: MockAuthService }] } }
);
// create component and test fixture
fixture = TestBed.createComponent(LoginComponent);
// get test component from the fixture
component = fixture.componentInstance;
// AuthService provided to the TestBed
testBedService = TestBed.get(AuthService);
// AuthService provided by Component, (should return MockAuthService)
componentService = fixture.debugElement.injector.get(AuthService);
});
it('Service injected via inject(...) and TestBed.get(...) should be the same instance',
inject([AuthService], (injectService: AuthService) => {
expect(injectService).toBe(testBedService);
})
);
it('Service injected via component should be and instance of MockAuthService', () => {
expect(componentService instanceof MockAuthService).toBeTruthy();
});
});
- End to End: A helper robot that behaves like a user to click around the app and verify that it functions correctly. Sometimes called "functional testing" or e2e.
- Integration: Verify that several units work together in harmony.
- Unit: Verify that individual, isolated parts work as expected.
- Static: Catch typos and type errors as you write the code.
Karma is a tool for executing source code against test code inside a browser environment. It supports the running of tests in each browser it’s configured for. Results are displayed on both the command line and on the browser for the developer to inspect which tests have passed or failed. Karma also watches the files and can trigger a test rerun whenever a file changes. At the root of the Angular project, we have the file
karma.conf that’s used to configure Karma.The contents should look something like this:
module.exports = function (config) {
config.set({
basePath: '',
frameworks: ['jasmine', '@angular/cli'],
plugins: [
require('karma-jasmine'),
require('karma-chrome-launcher'),
require('karma-jasmine-html-reporter'),
require('karma-coverage-istanbul-reporter'),
require('@angular/cli/plugins/karma')
],
client:{
clearContext: false // leave Jasmine Spec Runner output visible in browser
},
coverageIstanbulReporter: {
reports: [ 'html', 'lcovonly' ],
fixWebpackSourcePaths: true
},
angularCli: {
environment: 'dev'
},
reporters: ['progress', 'kjhtml'],
port: 9876,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: true,
browsers: ['Chrome'],
singleRun: false
});
};
Jasmine is a javascript testing framework that supports a software development practice called
Behaviour Driven Development, or BDD for short. It’s a specific flavour of Test Driven Development (TDD).Jasmine, and BDD in general, attempts to describe tests in a human readable format so that non-technical people can understand what is being tested.
For example if we wanted to test this function:
function message() {
return 'Hello world!';
}
We would write a jasmine test spec like so:
describe('Hello world', () => {
it('says hello', () => {
expect(message())
.toEqual('Hello world!');
});
});
- The
describe(string, function)function defines what we call a Test Suite, a collection of individual Test Specs. - The
it(string, function)function defines an individual Test Spec, this contains one or more Test Expectations. - The
expect(actual)expression is what we call an Expectation. In conjunction with a Matcher it describes an expected piece of behaviour in the application. - The
matcher(expected)expression is what we call a Matcher. It does a boolean comparison with the expected value passed in vs. the actual value passed to the expect function, if they are false the spec fails.
Built-in matchers
expect(array).toContain(member);
expect(fn).toThrow(string);
expect(fn).toThrowError(string);
expect(instance).toBe(instance);
expect(mixed).toBeDefined();
expect(mixed).toBeFalsy();
expect(mixed).toBeNull();
expect(mixed).toBeTruthy();
expect(mixed).toBeUndefined();
expect(mixed).toEqual(mixed);
expect(mixed).toMatch(pattern);
expect(number).toBeCloseTo(number, decimalPlaces);
expect(number).toBeGreaterThan(number);
expect(number).toBeLessThan(number);
expect(number).toBeNaN();
expect(spy).toHaveBeenCalled();
expect(spy).toHaveBeenCalledTimes(number);
expect(spy).toHaveBeenCalledWith(...arguments);
Setup and teardown
beforeAll: This function is called once, before all the specs in describe test suite are run.
afterAll: This function is called once after all the specs in a test suite are finished.
beforeEach: This function is called before each test specification, it function, has been run.
afterEach: This function is called after each test specification has been run.
We might use these functions like so:
describe('Hello world', () => {
let expected = "";
beforeEach(() => {
expected = "Hello World";
});
afterEach(() => {
expected = "";
});
it('says hello', () => {
expect(message())
.toEqual(expected);
});
});
Protractor is an end-to-end test framework for Angular. It runs your tests inside a real browser, interacting with it as real person would. Unlike unit tests, where we test individual functions, here we test the entire logic. Protractor is able to fill in forms, click buttons and confirm that the expected data and styling is displayed in the HTML document. Just like Karma, Protractor has its own configuration file at the root of your Angular project,
protractor.conf:const { SpecReporter } = require('jasmine-spec-reporter');
exports.config = {
allScriptsTimeout: 11000,
specs: [
'./e2e/**/*.e2e-spec.ts'
],
capabilities: {
'browserName': 'chrome'
},
directConnect: true,
baseUrl: 'http://localhost:4200/',
framework: 'jasmine',
jasmineNodeOpts: {
showColors: true,
defaultTimeoutInterval: 30000,
print: function() {}
},
onPrepare() {
require('ts-node').register({
project: 'e2e/tsconfig.e2e.json'
});
jasmine.getEnv().addReporter(new SpecReporter({ spec: { displayStacktrace: true } }));
}
};
LoginComponent.ts
import {Component, EventEmitter, Input, Output} from '@angular/core';
export class User { (1)
constructor(public email: string, public password: string) {
}
}
@Component({
selector: 'app-login',
template: `
<form>
<label>Email</label>
<input type="email"
#email>
<label>Password</label>
<input type="password"
#password>
<button type="button" (2)
(click)="login(email.value, password.value)"
[disabled]="!enabled">Login
</button>
</form>
`
})
export class LoginComponent {
@Output() loggedIn = new EventEmitter<User>(); (3)
@Input() enabled = true; (4)
login(email, password) { (5)
console.log(`Login ${email} ${password}`);
if (email && password) {
console.log(`Emitting`);
this.loggedIn.emit(new User(email, password));
}
}
}
- 1.We create a User class which holds the model of a logged in user.
- 2.The button is sometimes disabled depending on the enabled input property value and on clicking the button we call the login function.
- 3.The component has an output event called loggedIn.
- 4.The component has an input property called enabled.
- 5.In the login function we emit a new user model on the loggedIn event.
LoginComponent.spec.ts
describe('Component: Login', () => {
let component: LoginComponent;
let fixture: ComponentFixture<LoginComponent>;
let submitEl: DebugElement;
let loginEl: DebugElement;
let passwordEl: DebugElement;
beforeEach(() => {
TestBed.configureTestingModule({
declarations: [LoginComponent]
});
// create component and test fixture
fixture = TestBed.createComponent(LoginComponent);
// get test component from the fixture
component = fixture.componentInstance;
submitEl = fixture.debugElement.query(By.css('button'));
loginEl = fixture.debugElement.query(By.css('input[type=email]'));
passwordEl = fixture.debugElement.query(By.css('input[type=password]'));
});
});
Testing @Inputs
To test inputs we need to do things:
- We need to be able to change the input property enabled on our component.
- We need to check that the button is enabled or disabled depending on the value of our input property.
it('Setting enabled to false disables the submit button', () => {
component.enabled = false;
fixture.detectChanges();
expect(submitEl.nativeElement.disabled).toBeTruthy();
});
Testing @Outputs
it('Entering email and password emits loggedIn event', () => {
let user: User;
loginEl.nativeElement.value = "[email protected]"; (1)
passwordEl.nativeElement.value = "123456";
component.loggedIn.subscribe((value) => user = value);
submitEl.triggerEventHandler('click', null); (2)
expect(user.email).toBe("[email protected]");
expect(user.password).toBe("123456");
});
- 1.Setup data in our input controls.
- 2.Trigger a click on our submit button, this synchronously emits the user object in the subscribe callback!
Since the output event is actually an Observable we can subscribe to it and get a callback for every item emitted. We store the emitted value to a user object and then add some expectations on the user object.
We can test inputs by just setting values on a components input properties. We can test outputs by subscribing to an EventEmitters observable and storing the emitted values on local variables.
- Karma
- Protractor
- Karma
- Protractor
- Unit tests
- End-to-end tests
- Both of the above
- Services
- Components
- Both of the above
- AngularTestUtil
- NgTest
- NgTestBed
- TestBed
- Services
- Pipes
- Both of the above
- None of the above
- .test.ts
- .spec.ts
- Both of the above
- createTestModule
- configureTestModule
- configureTestingModule
- createTestingModule
- createComponent
- createTestingComponent
- configureComponent
- configureTestingComponent
- True
- False
The types of Testing looks are:
- 1.Unit Test
- 2.Integration Test
- 3.End to End (e2e) Test
The Unit Test is used to testing a single function, single components in Isolation. This is very fast.
In this Test, we are not able to say that everything is all right in the application. Just for a single Unit or function assure that working fine.
Example: app.component.ts
import { Component } from '@angular/core';
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent {
title = 'app';
}
app.component.spec.ts
import { TestBed, async } from '@angular/core/testing';
import { AppComponent } from './app.component';
describe('AppComponent', () => {
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [
AppComponent
],
}).compileComponents();
}));
it('should create the app', async(() => {
const fixture = TestBed.createComponent(AppComponent);
const app = fixture.debugElement.componentInstance;
expect(app).toBeTruthy();
}));
it(`should have as title 'app'`, async(() => {
const fixture = TestBed.createComponent(AppComponent);
const app = fixture.debugElement.componentInstance;
expect(app.title).toEqual('app');
}));
it('should render title in a h1 tag', async(() => {
const fixture = TestBed.createComponent(AppComponent);
fixture.detectChanges();
const compiled = fixture.debugElement.nativeElement;
expect(compiled.querySelector('h1').textContent).toContain('Welcome to app!');
}));
});
app.component.html
<div style="text-align:center">
<h1> Welcome to {{title}}! </h1>
</div>
<h2>Here are some links to help you start: </h2>
<ul>
<li>
<h2><a target="_blank" rel="noopener" href="https://code-sample.com/">Tour of Examples</a></h2>
</li>
<li>
<h2><a target="_blank" rel="noopener" href="https://code-sample.com/">CLI Documentation</a></h2>
</li>
</ul>
The Integration Testing is used to testing a component with templates and this testing containing more time as per comparison Unit Test.
The End to End Testing is used to testing the entire application looks like -
- 1.All User Interactions
- 2.All Service Calls
- 3.Authentication/Authorization of app
- 4.Everything of App
This is the actual testing of your append it is fast action. Unit testing and Integrations testing will do as fake calls but e2e testing is done with your actual Services and APIs calls.
Recommended Unit Testing Tools – Angular 4/2 and Angular
- Karma
- Jasmine and
- QUnit
Test Function – After installing everything as per your project requirements, CREATE your project. The following Steps –
- ng new YourTestProject
- ng install
- ng serve/ng test
Note – If you are going to development then type ng server command and if you want to test your project, you should type ng test command. After type ng test command and press inter. It’s taking some time to installing everything in your project for test.
- 1.
describe()– Test suit (just a function) - 2.
it()- The spec or test - 3.
expect()- Expected outcome.
Triple Rule of Testing –
- 1.Arrange - Create and Initialize the Components
- 2.Act - Invoke the Methods/Functions of Components
- 3.Assert - Assert the expected outcome/behaviour
The quick list of best practices.
- Use
beforeEach()to Initialize the context for your tests. - Make sure the string descriptions you put in
describe()andit()make sense as output - Use
after()andafterEach()to clean-up your tests if there is any state that may bleed over. - If any one test is over 15 lines of code, you may need to refactor the test
import { TestBed, async } from '@angular/core/testing';
import { AppComponent } from './app.component';
//describe – Test suit (just a function)
describe('AppComponent', () => {
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [AppComponent]
}).compileComponents();
}));
// it - The spec or test
it('should have hello property', function() {
const fixture = TestBed.createComponent(AppComponent);
const app = fixture.debugElement.componentInstance;
//expect – This Is For expected outcome.
expect(app.hello).toBe('Hello, Anil!');
});
});
Example: Login Testing
login.component.ts
import { Component, OnInit, EventEmitter,Input, Output, ViewEncapsulation } from '@angular/core';
@Component({
selector: 'app-login',
templateUrl: './login.component.html',
styleUrls: ['./login.component.css'],
encapsulation: ViewEncapsulation.None
})
export class LoginComponent implements OnInit {
@Output() loggedIn = new EventEmitter<User>();
@Input() enabled = true;
constructor() { }
ngOnInit() { }
login(email, password) {
if (email && password) {
this.loggedIn.emit(new User(email, password));
}
console.log(`Login ${email} ${password}`);
}
}
export class User {
constructor(public email: string, public password: string) {
}
}
login.component.spec.ts
import { async, ComponentFixture, TestBed } from '@angular/core/testing';
import {Component, DebugElement} from "@angular/core";
import {LoginComponent, User } from './login.component';
import {By} from "@angular/platform-browser";
describe('LoginComponent', () => {
let component: LoginComponent;
let fixture: ComponentFixture<LoginComponent>;
let submitElement: DebugElement;
let loginElement: DebugElement;
let passwordElement: DebugElement;
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [LoginComponent]
})
.compileComponents();
}));
beforeEach(() => {
fixture = TestBed.createComponent(LoginComponent);
component = fixture.componentInstance;
fixture.detectChanges();
submitElement = fixture.debugElement.query(By.css('button'));
loginElement = fixture.debugElement.query(By.css('input[type=email]'));
passwordElement = fixture.debugElement.query(By.css('input[type=password]'));
});
it('Setting enabled to false disabled the submit button', () => {
component.enabled = false;
fixture.detectChanges();
//Expected outcome
expect(submitElement.nativeElement.disabled).toBeTruthy();
});
it('Setting enabled to true enables the submit button', () => {
component.enabled = true;
fixture.detectChanges();
//Expected outcome
expect(submitElement.nativeElement.disabled).toBeFalsy();
});
it('Entering email and password emits loggedIn event', () => {
let user: User;
loginElement.nativeElement.value = "[email protected]";
passwordElement.nativeElement.value = "$ystem!1356";
// Subscribe to the Observable and store the user in a local variable.
component.loggedIn.subscribe((value) => user = value);
// This sync emits the event and the subscribe callback gets executed above
submitElement.triggerEventHandler('click', null);
//Expected outcome
expect(user.email).toBe("[email protected]");
expect(user.password).toBe("$ystem!1356");
});
});
login.component.html
<form>
<label>Email</label>
<input type="email" #email>
<label>Password</label>
<input type="password" #password>
<button type="button"
(click)="login(email.value, password.value)"
[disabled]="!enabled">Login
</button>
</form>
ng test
Using
TestBedTestBed.configureTestingModule({
providers: [AuthService]
});
The CLI can run unit tests and create code coverage reports. Code coverage reports show you any parts of our code base that may not be properly tested by your unit tests.
To generate a coverage report run the following command in the root of your project.
ng test --code-coverage
When the tests are complete, the command creates a new
/coverage folder in the project. Open the index.html file to see a report with your source code and code coverage values.If you want to create code-coverage reports every time you test, you can set the following option in the CLI configuration file,
angular.json:"test": {
"options": {
"codeCoverage": true
}
}
Code coverage enforcement
The code coverage percentages let you estimate how much of your code is tested. If your team decides on a set minimum amount to be unit tested, you can enforce this minimum with the Angular CLI.
For example, suppose you want the code base to have a minimum of 80% code coverage. To enable this, open the Karma test platform configuration file,
karma.conf.js, and add the following in the coverageIstanbulReporter: key.coverageIstanbulReporter: {
reports: [ 'html', 'lcovonly' ],
fixWebpackSourcePaths: true,
thresholds: {
statements: 80,
lines: 80,
branches: 80,
functions: 80
}
}
The thresholds property causes the tool to enforce a minimum of 80% code coverage when the unit tests are run in the project.↥ back to top
Installation
npm install chai mocha ts-node @types/chai @types/mocha --save-dev
Mocha is a JavaScript test framework running on Node.js and in the browser. Mocha allows asynchronous testing, test coverage reports, and use of any assertion library. Mocha gives us a Suite for describing, running and building tests but it does not give us a way to check values.
Chai is a BDD / TDD assertion library for NodeJS and the browser that can be delightfully paired with any javascript testing framework.
Basically, mocha is a framework and chai is a library. Let's go a little deeper in mocha. Mocha uses hooks to organize its structure.
- describe(): It's used to group, which you can nest as deep;
- it(): It's the test case;
- before(): It's a hook to run before the first it() or describe();
- beforeEach(): It’s a hook to run before each it() or describe();
- after(): It’s a hook to run after it() or describe();
- afterEach(): It’s a hook to run after each it() or describe();
Scenario 1: One test case
In this case, we can just call a solitary
it(), mocha will run this only test.it('Homer should drink beer', () => {
/** Test cases */
})
Scenario 2: A nested test case
In this case, we can nest some
describes() hooks and finally call it() to execute the test.describe('Abraham Simpson', () => {
describe('Homer Simpson', () => {
describe('Bart Simpson', () => {
it('Bart should skate', () => {
/** Test cases */
})
})
})
})
Scenario 3: Two test cases in one test
Here, inside the
describe() we have two it() that will execute the tests.describe('Homer Simpson', () => {
it('Bart should skate', () => {
/** Test cases for Bart */
})
it('Lisa should play sax', () => {
/** Test cases for Lisa */
})
})
Scenario 4: Run just once before the first test case
In this scenario, before the first
it() mocha will execute what is inside before(), but only once.