For: developers, architects and teamleads that want to incorporate unit-testing for their TypeScript projects
A couple of blog posts ago we’ve set up a basic build-line, in particular for TypeScript. In this post we’ll get our hands-on again and apply some automagic stuff for doing TDD and / or unit-testing on our builds.
note: this post only deals with the ‘how‘, not the ‘why‘ and ‘when‘. Read this if this has your interest.
Setting up the environment for unit testing
So what do we need:
Some testing framework (we go with Jasmine)
There are lots of unit-test tools (mocha, chai, sinon, etc) out there that are really good. I at this moment prefer Jasmine. It’s well documented, stays relevant, serves an atomic purpose, configurable and has plugins separated through the NPM repo.
Some orchestrator / runner
We need an orchestrator to launch our tests in browsers. We use Karma for this.
Some browsers
There’s so many you can use, but also should use. Karma facilitates that you can hook up your own browser (open multiple on multple machines if you want) to test with. If that’s too manual you can go with solutions like: PhantomJS, chrome automated testing with Selenium / Webdriver, or doing it through Browserstack and have it tested on multiple versions of multple browsers on multiple operatingsystems and their versions. Lucky you, te runner we chose (Karma) supports interfacing with all of these as part of your testline.
Some reporters
What would we need to get a bit of grip and feeling with our test-process.
- spec – show the entire spec of the units
- coverage – we want to know if we’ve actually covered most of our logic (again, why you would like to do this will be described in another article)
You convinced me, two thumbs up, let’s do this.
So our lovely NPM can help us quite a bit with this. Do as followed:
╭─tim@The-Incredible-Machine ~/Git/build-process ‹unit-tests*› ╰─➤ npm i jasmine-core karma karma-browserify karma-browserstack-launcher karma-jasmine karma-phantomjs-launcher karma-coverage karma-typescript-preprocessor phantomjs-prebuilt watchify karma-spec-reporter --save-dev
Next chapter.. ;-).
Instructing the runner
Karma needs to know a bit about what it should do when we’ve asked for a test.
karma.conf.js
module.exports = function (config) {
config.set({
basePath: '',
frameworks: ['browserify', 'jasmine'],
files: [
'spec/**/*_spec.ts'
],
exclude: [],
preprocessors: {
'spec/**/*.ts': ['browserify','coverage']
},
browserify: {
debug: true,
plugin: [['tsify', {target: 'es3'}]]
},
reporters: ['spec', 'coverage'],
port: 9876,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: true,
browserDisconnectTimeout: 1000,
browserDisconnectTolerance: 0,
browserNoActivityTimeout: 3000,
captureTimeout: 3000,
browserStack: {
username: "",
accessKey: "",
project: "build-process",
name: "Build-process test runner",
build: "test",
pollingTimeout: 5000,
timeout: 3000
},
coverageReporter: {
type: 'text'
},
customLaunchers: {
ie10: {
base: "BrowserStack",
os: "Windows",
os_version: "7",
browser: "ie",
browser_version: "10"
},
chrome: {
base: "BrowserStack",
os: "Windows",
os_version: "10",
browser: "chrome",
browser_version: "latest"
},
},
browsers: ['PhantomJS'],
singleRun: false
})}
don’t forget to create the directory that is scanned for your _spec.ts files
Extending the Makefile
Add your test-routine to the makefile
.PHONY: [what was already in there] test tdd
and add the rules:
test:
node_modules/.bin/karma start --single-run
tdd:
node_modules/.bin/karma start
Getting definitions of Jasmine
Since your code is written in TypeScript, your tests preferably are also written in TypeScript. You’ll need some definitions of the capabilities of Jasmine in order to use it properly. Luckily the people of typings are geniuses and supplied such a definition for us!
╭─tim@The-Incredible-Machine ~/Git/build-process ‹unit-tests*› ╰─➤ node_modules/.bin/typings i jasmine --source="dt" --global jasmine └── (No dependencies)
Test if we can test
Oh boy that is a nice title :-). Let’s write some nonsense first, so we can write tests for it later.
The nonsense
Now create some simple example module like ts/example_module.ts:
type someCallback = (someString: string) => string;
export default class example_module {
constructor(private someVar: string, private callback: someCallback) {
}
public some_method(){
console.log('some method ran!');
}
public get_string(): string {
this.some_method();
return this.callback(this.someVar);
}
}
There’s a range of nonsense that can be applied in even more bizarre ways that I don’t intend on pursuing if you don’t mind. This should suffice 🙂
Let’s test this nonsense
Create this testfile in spec/example_module_spec.ts
Generally it’s a good idea to separate the tests from the project since they otherwise clutter the area you’re working in. But do try to mimic the structure that’s used in your normal ts folder. This allows you to find your files efficiently. We append _spec to the filename, because when your project grows, it’s not uncommon to create a helper or two, which shouldn’t be picked up automatically.
/// <reference path="../typings/index.d.ts" />
import ExampleModule from "../ts/example_module"
describe('A randon example module', () => {
var RANDOM_STRING: string = 'Some String',
RANDOM_APPENDED_STRING: string = ' ran with callback',
callback = (someString: string): string => {
return someString + RANDOM_APPENDED_STRING;
},
exampleModule: ExampleModule;
/**
* Reset for each testcase the module, this enables that results
* won't get mixed up.
*/
beforeEach(() => {
exampleModule = new ExampleModule(RANDOM_STRING, callback);
spyOn(exampleModule, 'some_method');
});
/**
* testing the outcome of a module
*
* Should be doable for almost all methods of a module
*/
it('should respond with a callback processed result', () => {
let response = exampleModule.get_string();
expect(response).toBe(RANDOM_STRING + RANDOM_APPENDED_STRING);
});
/**
* testing that specific functionality is called
*
* You could make use of this, when you expect a module to call
* another module, and you want to make sure this happens.
*/
it('should have called a specific method each time the string is retrieved', () => {
// notice that, because of the beforeEach statement, the spy is reset
expect(exampleModule.some_method).toHaveBeenCalledTimes(0);
// execute logic twice
exampleModule.get_string();
exampleModule.get_string();
// expect that the function is called twice.
expect(exampleModule.some_method).toHaveBeenCalledTimes(2);
});
});
The result:
╭─tim@The-Incredible-Machine ~/Git/build-process ‹unit-tests*› ╰─➤ make test node_modules/.bin/karma start --single-run 08 12 2016 22:58:35.109:INFO [framework.browserify]: bundle built 08 12 2016 22:58:35.115:INFO [karma]: Karma v1.3.0 server started at http://localhost:9876/ 08 12 2016 22:58:35.116:INFO [launcher]: Launching browser PhantomJS with unlimited concurrency 08 12 2016 22:58:35.130:INFO [launcher]: Starting browser PhantomJS 08 12 2016 22:58:35.380:INFO [PhantomJS 2.1.1 (Linux 0.0.0)]: Connected on socket /#RxSPDX6Lu-LvxyP2AAAA with id 76673218 PhantomJS 2.1.1 (Linux 0.0.0): Executed 2 of 2 SUCCESS (0.04 secs / 0.001 secs) --------------|----------|----------|----------|----------|----------------| File | % Stmts | % Branch | % Funcs | % Lines |Uncovered Lines | --------------|----------|----------|----------|----------|----------------| spec/ | 100 | 100 | 100 | 100 | | app_spec.ts | 100 | 100 | 100 | 100 | | --------------|----------|----------|----------|----------|----------------| All files | 100 | 100 | 100 | 100 | | --------------|----------|----------|----------|----------|----------------| ╭─tim@The-Incredible-Machine ~/Git/build-process ‹unit-tests*› ╰─➤
Or as my lovely console likes to tell me in more color:
Check the PR for the actual code.
Want more? Any ideas for the next one? Let me know or use the poll on the right side of the screen!