How To Automate Jasmine Tests for Typescript with Gulp

I have a gulp workflow that I’d like to share with the javascript community. This workflow automates the compilation of typescript and tests the generated code with Jasmine.

Why Another Workflow?

I personally like to build my own workflows whenever possible.

I know that advanced editors like Visual Studio have tools that automate a lot. However, I feel that software development is too complicated for a single workflow to automate everything.

IMO, there are simply too many details in software development. At some point, you always need to do something custom.

Enter Gulp

I feel that gulp has the best approach to creating workflows, currently.

Gulp has a massive collection of plugins that you can reuse for common tasks, and you can stitch various plugins together programmatically.

Creating the Workflow

I will provide a step-by-step walk-through that shows how to use the linux command line to setup a project. You may not be able to use this process if you use something like Visual Studios to setup your typescript applications.

Create the Folder Structure

Create the following folder structure

src/ts

src/js

spec

with the following commands

We will put our typescript code in src/ts, our generated javascript code into src/js, and our jasmine tests into spec.

Setup the Project

Initialize the directory as a node project.

Install node plugins

Create a custom node module

We will need to take the contents of the generated javascript file that typescript produces and evaluate it in the jasmine files. In order to make this easier, we will create a helper module called __require.js in the root folder.

By design, we will place all generated javascript code under src/js. If we had an alternate location then we would have to reflect that in __require.js.

Alter NODE_PATH

In order to make __require.js discoverable by node, we can change the NODE_PATH environment variable to include the current directory

Create Program and Unit Tests

Create a Set class with Typescript at src/ts/Set.ts

This Set class is a very naive implementation of a basic set for the sake illustration.

Place the following Jasmine code under spec/Set.spec.js

These lines of code in Set.spec.js deserves some explaining:

By design, node modules need to follow the commonjs format. If you “require” a file that does not follow the commonjs format then node will return an empty object.

Since Typescript does not actually generate code that obeys the commonjs format, we need to create a method for us to get the generated code into the scope of a jasmine test.

I created __require.js because it makes it very easy to include the contents of a file under the directory I designated as generated code.

Create Gulp Tasks

We now have everything in place to execute our workflow. Create gulpfile.js under the root directory with the following contents.

This workflow will do the following:

compile all typescript code in the src/ts directory

place the generated javascript code in the src/js directory

run all jasmine tests in the spec directory

runSequence will make sure that your workflow will compile all the Typescript files first before gulp runs the unit tests. If we did not use runSequence then gulp would run the tests concurrently with the compilation.

In order to initiate this workflow we simply have to execute gulp from the directory like so:

Conclusion

In practice, there are many different ways of creating workflows. I don’t claim that this is somehow the best or only way to do it.

I hope that this particular example can help you build a workflow that works best for you.

4 thoughts on “How To Automate Jasmine Tests for Typescript with Gulp”

Hey man, thanks a lot for this, was really nice easy and helpful. One question though, can you extend this by providing some sort of coverage support? I’m having a hard time dealing with this, given the fact we’re using custom require.

Hi there. Typescript now generates code that is commonjs compliant. This method is a hack that really only made sense when various tools didn’t obey standards. Things have changed quite a bit, now; so, I actually would not recommend this method anymore. I’ll create a new blog at some point that addresses your use case because its something that I see a lot.