build with purpose

Testing with Karma and Wallaby

I’ve recently been spending some time trying to improve my development techniques and one area I’ve been focusing on improving on is my testing practices. It isn’t obvious to new programmers as to why you might want to start testing your code. After all, if you can test out something that you’ve written that works shouldn’t it always work? Code can usually be assumed to be deterministic right?

While that’s generally true with small programs, scripts, and school projects, it doesn’t hold up when it comes to larger programs and software. Requirements will change, updates will break things, and it can be hard to remember why you wrote that piece of code to handle that weird edge case. Concurrency issues can break determinism and lead to misdirection when trying to debug the problem.

I see all of the above as issues that can be reduced with the help of better testing with a wide coverage.

A table of technologies

Tool Description
Karma Test runner for Javascript which can easily be hooked into many testing frameworks and build systems. Pretty easy to customize and configure
Jasmine Javascript Testing framework with a simple and easy to read syntax for writing tests
Wallaby A editor/IDE plugin for constantly running Javascript unit tests as you develop. Offers code coverage tooling and in-editor error display functionality. There is a free trial but ultimately Wallaby.js requires a paid license ($100+ per user)
Atom Community-driven editor with lots of functionality and plugins

I use all of the above technologies in my testing stack. I write my test in Jasmine within my Atom editor against my frontend Angular codebase. These tests are constantly run through Wallaby to ensure that my changes haven’t broken any existing code and enables me to pursue TDD (Test Driven Development) practices. I keep my Karma test build up-to-date so that other users of the code and builds can still run tests successfully.

Wallaby and Karma overlap a bit in functionality but the convenience of having both in my build outweighs the overhead cost of adding a file and messing with the configuration every time I make a big change.

A snippet of a Jasmine test in one of my projects

describe('Login component', function () {
  it('should send login informatin to login service if login successfull', function() {
    var deferred = $q.defer();
    deferred.resolve({test: 'data', code: 'AWESOMESAUCE'});
    spyOn(auth2, 'grantOfflineAccess').and.returnValue(deferred.promise);
    spyOn(authToken, 'setToken').and.returnValue();

    $httpBackend.when('POST', API_URL + 'auth/google')
      .respond(200, {message: 'Successfully inserted entry', type: 'OK', token: 'TOKEN'});

    window.auth2 = auth2; // push to global scope
    scope.$$childHead.loginCtrl.login();
    $httpBackend.flush();
    scope.$apply();

    expect(auth2.grantOfflineAccess).toHaveBeenCalled();
    expect(authToken.setToken).toHaveBeenCalledWith('TOKEN');
    expect($state.current.name).toEqual('home');
  });
});

This is currently the testing stack I like as I start to write more elaborate tests on the backend that start spying and mocking modules. I’m thinking about sticking with Jasmine for consistency but I’ve also heard some good things about Mocha. Any reasons I might want to choose one over the other?

Make my day and share this post:

Other posts to peak your interest:

  • Understanding Visual Testing
  • The Redux Saga Black Box
  • What my college degree gave me
  • Technical Leaders Enabling Stronger Teams
  • Finding Your Gateway to Learning Vue
  • Why Write Server Rendered Frontend Apps
  • comments powered by Disqus
    © 2019. All rights reserved.