AMA: Testing an Angular app

Ben asks…

I’ve been working with angular a while now but I have to admit, the testing side throws me. Every time I start to tackle it, I find myself distracted from the test I want to write by all of the things I need to mock. Sometimes it feels like I need to build an entire mock framework to test one feature. Maybe I’m doing it wrong. Any tips appreciated, whether practical or even just the right headspace for approaching it :)

My response…

I haven’t worked with angular applications directly but I’ve worked on React applications and I’m guessing the approach to unit testing these will be similar.

I would start as simple as possible with the smallest test that would possibly work. If you find that you need an entire mock framework to test a feature it sounds like your components may need to be broken down further into smaller components as you have too many dependencies that need to be mocked. If you have smaller components that only require a single dependency then these components should be easier to test as the dependencies will be easier to mock.

With smaller components I would also encourage you to be able to pass in dependencies. This allows you to easily mock/override dependencies for testing purposes – known as dependency injection. I wrote about this using a simple JavaScript example previously which you may want to read.

If retrofitting unit tests into your app is still too difficult you could try to automated some key end-to-end scenarios using Protractor, but I’d discourage you from going overboard since these can quickly get out of hand. You may still benefit from having a few of these tests even if you get unit testing of small components working well to ensure the small components work well together.

I hope this helps you Ben 😊

Unit Testing Randomness

Let’s imagine hypothetically you were working on software that placed landmines in a minefield grid and you had a function that given the dimensions of a minefield, and a safe cell, you had to randomly place a certain number of landmines in the other cells of the grid. It looks something like this:

Continue reading “Unit Testing Randomness”

Why I don’t like Jasmine JavaScript unit tests (for MVC web apps)

Update 11-Feb-2013: After some feedback, I would like to clarify what I am talking about here: I am talking from experience in applications not purely written in JavaScript: for example a MVC application written with say C# with JavaScript added to pages.

I’m really not a big fan of Jasmine JavaScript unit tests for applications not written purely in JavaScript. Here’s why:

jasmine logo

Most modern web applications use JavaScript as a way to provide client side validation and interaction. Most of this JavaScript manipulates the Document Object Model (DOM) of the browser, therefore the JavaScript is coupled to the DOM using ids or classes of elements.

As most web pages are dynamically rendered by the server, Jasmine, the JavaScript unit test framework, can’t run against the ‘real’ DOM as it appears in the application, so what it does is duplicates parts of the DOM to test the JavaScript is working properly based upon this duplication.

As there’s no reliance on the real application or its DOM, these tests run super fast, you can run thousands of JavaScript tests in seconds which is pretty amazing.

The problem becomes that over time the real DOM in the application is changed but the Jasmine tests and its own duplicated DOM is not! This means that often I find that all Jasmine tests pass (as they have to for a new version to be deployed to QA) but the JavaScript doesn’t work in the application because an id or class name has been changed and someone ‘forgot’ to update the Jasmine tests.

Tests that don’t pick up valid errors are worthless, and I continually find myself getting annoyed that all the Jasmine tests have passed, but JavaScript is broken and our application doesn’t work.

Another downside is that Jasmine tests are only as good as the JavaScript engine they are run against. We run our Jasmine tests in a headless PhantomJS browser, which is fast, but most of our JavaScript bugs are found in Internet Explorer, particularly earlier versions of it, so Jasmine tests again are worthless.

I don’t know of a way to overcome these downsides to Jasmine that I have mentioned. What we do have is a suite of end to end acceptance tests that run in 5 different ‘real’ browsers that check the JavaScript works correctly. Whilst these take 8 minutes to run per browser, they pick up a lot more JavaScript issues than Jasmine.

I am not still not sure whether it is worth investing the time and effort in Jasmine tests when they don’t provide sufficient confidence that our application ‘works’.

What have others experiences been with Jasmine JavaScript unit testing?