Jasmine Tutorial: Unit Testing Promises In Angular Services

Leave a comment Standard

So recently I’ve been doing a lot of Angular unit tests with Jasmine and Grunt. I have to say, testing promises is extremely frustrating and most of the examples I found out there either 1) didn’t work or 2) wouldn’t allow you to test content in a then block if you had multiple chained promises, or if you had a promise being called from and returned from another service. After many hours of frustrating trial and errors I found a solution I’m happy with so I want to share.

Let’s assume this is your controller:

'use strict';

angular.module('myModule').controller('myCtrl', ['$scope', 'api',
function ($scope, $api) {

  $scope.data = null;
  $scope.message = null;

  * Load some data from the API service
  * @return boolean
  $scope.loadData = function () {

    var config = {
      method: 'GET',
      url: 'http://api.domain.com/someRESTfulEndpoint',
      headers: {'Content-Type': 'application/json'},
      data: null

    return $api.load(config).then(function (request) {
      if (request) {
        $scope.message = 'Your data was successfully loaded';
        $scope.data = request.response;
        return true;
      } else {
        $scope.message = 'The API service failed';
      return false;

And here is the service making your API calls:

'use strict';

angular.module('myModule').service('api', ['$rootScope', '$http',
  function ($rootScope, $http) {

    * Makes the $http request given the proper configuration options
    * @param Object configruation for the $http request
    * @return Object $http promise that resolves to request payload or error
    this.load = function (options) {
      return $http({
        method: options.method || 'GET',
        url: options.url || 'http://api.domain.com/someDefaultEndpoint',
        headers: options.headers || null,
        data: options.data || null
        function (request) {
          //we got a response back, return just the API payload data
          if (request.status === 200 && request.data) {
            return request.data;
          } else {
            return {
              results: false,
              message: 'API request error',
              response: request

Finally, this is your working unit tests:

'use strict';

describe('testing myModule', function () {


  var $controller, $rootScope, $scope, $api, $httpBackend, $q;

    inject(function (_$controller_, _$rootScope_, api, _$httpBackend_, _$q_) {
      $controller = _$controller_;
      $rootScope = _$rootScope_;
      $httpBackend = _$httpBackend_;
      $q = _$q_;
      $api = api;
      $scope = $rootScope.$new();

      $httpBackend.when('GET').respond('test http GET call');
      $httpBackend.when('POST').respond('test http POST call');

      $controller('myCtrl', {
        $scope: $scope,
        $api: $api

  it('has a $scope.loadData() function', function() {

    var testConfig = {
      method: 'POST',
      url: 'http://api.domain.com/endpoint',
      data: { some: 'data'}

    var fakeData = { data: 'is fake' };

    //we spy on the API service and also return a fake promise call
    spyOn($api, 'load').and.callFake(
      function() {
        var deferred = $q.defer();
        deferred.resolve({result: true, response: fakeData});
        return deferred.promise;

    $scope.loadData(testConfig); //call the function we're testing in the controller
    $scope.$apply(); //we have to call this so Angular will try and resolve the promise
    expect($api.load.calls.count()).toEqual(1); //make sure it's called the api service
    expect($scope.message).toEqual('Your data was successfully loaded');

  it('returns an error if the API fails', function() {

    var testConfig = {
      method: 'POST',
      url: 'http://api.domain.com/endpoint',
      data: { some: 'data'}

    spyOn($api, 'load').and.callFake(
      function() {
        var deferred = $q.defer();
        result: false,
        message: 'api error'
      return deferred.promise;

    expect($scope.message).toEqual('api error');

Continue reading


Tutorial: Black Box Testing

Leave a comment Standard

What Is Testing?

Testing is a way to check if your software is running properly by purposefully trying to find errors so they can be corrected or prevented from happening in the future.

Why Should You Test?

One thing that’s important to understand is that software testing cannot prevent all bugs or errors. Instead, it can identify bugs and errors so they can be corrected. If testing is used in conjunction with software development it can quickly and easily identify when and where new changes to the software have caused issues or problems so they may be corrected. However, since testing uses a specific set of conditions to test with, it will not cover all cases and prevent all bugs — but it can often prevent introducing new bugs  for those specific conditions when new or additional software changes are made.

Downsides of Testing?

This is kind of a glass half full, glass half empty question. While testing is helpful in finding bugs it is also a tedious process and it cannot prevent all bugs from occurring. In addition, good testing conditions are hard to establish especially with highly complex and multi-variable software.

Black Box Testing

Tests the input and outputs of the software and focuses on the software behavior and it’s performance efficiency. In black box testing there is no knowledge of how the internal system works, only that when given an input you get the correct output.

Tester Inputs    -> Software
(internals unknown)
->    Software Outputs

Equivalence Partitioning

Test conditions are divided into groups of functionality that exhibit similar behaviors. Instead of testing the functionality individually, which may take a long time, you can test one section of functionality from the group because the other functionality is likely to exhibit the same behavior given the same conditions.


In the image above you can see an example of equivalence partitioning. Each 9 block square of the Sudoku puzzle is a smaller component of code that behaviors similarly to the others. Therefore if we wrote an equivalence test to pass in a number to one of the boxes on the Sudoku board it would return true/false if a duplicate number was found in that section of the box. This test would work exactly the same way for the other colored partitions, therefore there’s no need to write a test for each of the individual partitions.

Boundary Value Analysis Testing

Often times a problem arises with a piece of software when the input value is at the boundary of the acceptable input values. With boundary value testing you identify the valid and input partitions and then test the high and low values of that boundary.

Let’s go back to our original Sudoku puzzle. In this game we allow the numbers 1-9 in each of the squares. That means numbers below 1 and above 9 are invalid. So we can separate our input partition into three partitions, two invalid and one valid:input-boundary-partitions.jpg

In this case we test the value before and right after the ends of our valid partitions. That means testing 0 and 1 and then 9 and 10.


Another approach to boundary testing is to only test the upper and lower values of the valid partition and the upper and lower boundaries of the invalid partitions. For example, testing to make sure 0, 10 are invalid and 1,9 are valid.


Another way to boundary test is to include one number after the boundary and one number before the boundary, as well as the boundary itself. That would mean testing 0, 1, 2 where 1 is the lower boundary and 8, 9, 10 where 9 is the upper boundary.


Decision Table Testing

This allows you to take a complex rule set and and translate it to it’s corresponding actions. Each rule goes in the top section of the table and each action goes in the bottom. Then you create a grid with different rules selected in the conditions section and the corresponding action that should happen when those conditions are met.

Let’s take our Sudoku for example and make a simple decision table for it.

Conditions Rules
User enters valid number Y Y Y Y N N N N
Duplicate number in that grid section Y Y N N Y Y N N
Grid  has no more empty spaces Y N Y N Y N Y N
Highlight the grid square  X  X  X  X  X  X
Validate the user input X  X X  X  X  X  X  X
Check for duplicate numbers X  X X  X X  X X  X
Show an error X X X X  X  X
Check for a winning game  X

In our decision table we added some of the possible game conditions and then outcomes we expect if those conditions are or are not met. Now we can test our game for each of these conditions and assert that the predicted outcomes have been met successfully.

State Transition Table Testing

This table uses the different states of the software and what they should transition to in order to develop tests. First you start with a state diagram, then you translate that into a state transition table. Let’s continue with our Sudoku example where we have a few major states of the game: drawing the board, validating input, showing an error message, checking to see if the game is won or not, handling a winning game, showing a final score and then clearing the board to start a new game.


To make our state transition table we put our state down one column and user inputs across the top rows. Then we fill in the table according to the input to indicate what states the software can transition to once the input is given. So, when Sudoku validates the user’s input after they enter a number it will either find valid input and check the game status to see if they won, or it will recognize an invalid or duplicate input and show them an error message.

Enter A Number Press Clear Submit Score
Draw Board Validate Input Clear Board
Validate Input Check Game Status
Validate Input Show Error Message
Show Error Message Draw Board
Clear Board Draw Board
Show Score  Draw Board
Check Game Status Draw Board
Check Game Status Game Over
Game Over Show Score

Use Case Testing

This kind of testing approaches the different interactions that an actor will  typically use in order to accomplish their goals when they are using the software. An actor is anyone who will be interacting with the software.


If we refer back to our Sudoku example we have only one actor, the person playing the game. Then we define all of the different goals our user will need to accomplish as it’s own use case. Now we can tailor our tests to ensure that all of these different use cases are present and working in the final version of our software.

Fuzz Testing

With fuzz testing you enter values that are outside of the expected input, as well as longer and shorter than the expected input.

fuzz_testing.jpgSince our Sudoku expects a single integer that means we would perform fuzz testing with non-integer values, as well as empty values and more than the maximum characters expected. In the example below we test floats, strings, characters and values with more than 1 character.

Exploratory Testing

This is a by-product of running other black box testing. As a tester, as you write tests for the software you will, by your own creativity, observation or personal experience, think of other good tests that you want to include during the testing of your software.

For instance, if you’re familiar with Cross Site Scripting  Injections (XSS) and while you’re doing Fuzz testing you realize you can enter more than a single character into the Sudoku input box you may then decide to run additional XSS injection tests to make sure the software cannot be compromised in this way.

Grey Box Testing

This is just like black box testing except the tester does have some knowledge of the internal data structures or algorithms used in the software while they are running their black box tests. The tester may only have knowledge of the data structures or a limited access to the code base while they are performing their black box tests.

Tester Inputs    -> Software
(internals partially known)
->    Software Outputs

Testing In Practice

Generally you find three schools of thought when it comes to testing in a real development situation, each have their own reasons for using or not using tests.

No Testing

Testing is extremely time consuming and if you’re developing software that changes often and in a large way the tests you’ve written may not even be relevant anymore. For this reason in rapid development and prototyping you’re less likely to include any kind of testing.

Some Testing

This school of thought is that it’s good to have tests for your software but they don’t need to be exhaustive. Generally if you’re doing some testing you’ll set a threshold for the amount of testing you must have in order for the testing to be considered “good enough”. This is usually found in legacy software systems or systems that are so large and didn’t have tests before than adding in tests to the existing code base would be an enormous and/or exhaustive effort. These tend to be developers that recognize the benefit of testing however, they also realize that testing will not stop or prevent all bugs from ever happening and the software is changing fast enough that tests need not provide 100% coverage on the code base. Also, some things are much harder or impossible to test so achieving tests for 100% of the software may not be possible.

Test Driven Development

In this practice all tests are written before the code has been developed and the test should describe what the code will do. Generally in test driven development you don’t see a lot of documentation in the code base because the tests are representative of that documentation (or should be). Software created with test driven development tends to have fewer bugs but the amount of time invested on creating and modifying tests as the code base changes is a large part of the development cycle for the software. In addition, there are times when it’s impossible to test a piece of code that’s been written which leaves you to question if the code should be re-designed or the test needs to be re-written causing a lot of circling back during the development process.

The Game Plan: I’m Not a Programmer

Leave a comment Standard

If you’ve been following my Game Plan series then you’ve already put your game idea to paper and have a game design document done along with a set of small, easy to complete tasks to get you started working on a MVP or minimum viable product.

But What If You Can’t Do It?

If you lack the skills to do something during this game design journey then it really boils down to these two options:

  1. You outsource the work to someone who knows how to do it. If you go this route then you have to account for what it would cost to hire a knowledgeable person. Don’t expect that you will be able to find someone to do the work for free as this is often not the case, no matter how awesome your game idea is.
  2. Resign yourself to learning a new skill. You don’t have to be an expert programmer to make a game, just an adequate one. If you’re going to invest time into learning a new skill then don’t dwell on it for too long. Learn enough that you feel confident to complete the task at hand and then move on. Investing too much time in learning a skill will start you down a path further and further from a working game.

Outsourcing The Work

If you’ve decided to outsource the work here are a few things you should consider when hiring someone.

  1. Be prepared to pay — nothing in life is free!
  2. Ask for current examples of their work
  3. Communication is key, make sure you can easily understand each other
  4. Setup a timeline and consequences for BOTH parties not sticking to it
  5. Be available to answer questions and be flexible to suggested adjustements, changes and/or improvements
  6. Put everything in writing and set all expectations up front

Learning It Yourself

If you’ve decided to learn how to do it yourself then find a good resource that you like and understand and dig in until you can complete the task at hand. Try not to go above and beyond the task you’re trying to complete — remember that this will steer you away from delivering a minimum viable product. Here’s some good resources to get you pointed in the right direction:



Music & Sound


HTML5 Game Tutorial: Alien Invasion

Leave a comment Standard

alieninvasion_screenshotThis is a little side project I did this week that I would like to share. It’s forked from another project I found on gitHub and liked it so much I decided to spend some time adding new features to brush up on my HTML5 skills. It uses the Canvas and Audio with JS to create multiple levels and bosses and power ups and different types of enemies and fire power. It’s still a work in progress but I’m not going to hand out the final version here but there’s plenty in the code base for you to take it and make it your own or continue to improve upon it. Click the Remix button to fork it and view the source on Thimble.

Here’s a video of the game if you’re too lazy to try it out yourself:

Sample Angular Website

Leave a comment Standard

So I’ve seen a lot of people using AngularJS but I see very few examples of a website made using it. That’s why I decided to post an example website to give you an idea of what a full website looks like using AngularJS. It has samples of some of the things you’ll commonly find in a website made entirely with Angular:

  •  Navigation & Routing
  • Providers & Directives
  • Controllers & Config Blocks
  • Data Calculations
  • Filtering

Sorry if you’re looking for Angular 2.0, this was made with Angular 1.5.8. View, fork and/or edit the files on Plunker!

The Game Plan: Getting Started

Leave a comment Standard

Your game design can run fairly smoothly or it can be a continuous cesspool of hardships and setbacks and pain points. In the next few series of posts I’m going to try and help walk you through the process of getting your game up and off the ground, from what you’re envisioning in your head to an actual working version. So, let’s get started.

1. Get It Out Of Your Head

It’s time you pull out a pencil, pen, or open your laptop to a writing program. First thing’s first, you have to get your game out of your head. Write it down and put it somewhere you can reference it later.

2. Writer’s Block

So if you’ve opened a text editor or you have a pen in your hand you’ve successfully completed step one. Now, what do you write? I like to start with the five W’s:


  • Does your game appeal to a specific age range or interest group or gender or even ethnic background?
  • Will you have a large audience your game will appeal to or a small audience?
  • What are the benefits and downsides of the audience you’ve identified?


  • What kind of game are you trying to make?
  • What programming language best suits this kind of game?
  • Does it fit into a specific genre of game or does it span multiple genres?
  • Does it embody a completely new genre?
  • Can you find other games that are similar to the game you are trying to make? If so, what do these games do well and where do fall short?
  • Are there lots of other games on the market similar to the type of game you’re trying to make?
  • What will your charge for your game?
  • What do other, similar games of this type charge?
  • What are the benefits and downsides of the type of game you’re trying to make?


  • Where does your game take place?
  • What kind of maps or features or environment are unique to your game?
  • What are the benefits and downsides of where your game takes place?


  • When will you have time to work on this game?
  • When can you start this game?
  • When can you fund the development of this game?
  • What are the benefits and downsides of developing this game?


  • Why are you making this game?
  • Why is your game unique?
  • Why will your game stand out from the crowd?
  • Why will people choose to play your game over other similar games?
  • Why will people pay for your game?
  • What are the benefits and downsides of making this game?

3. Make A Design Document

Your design document is a refined version of everything you’ve written down in step 2. Go back and really analyze what your goals for the game are and if what you’ve written down makes sense in the larger picture. Sometimes a good idea you have for one area of the game will conflict or make another part of the game tedious, uninspired or downright frustrating. For a game design document I like to use the following format:

  1. Intro
    • What is the vision for your game and a short description of how the game is played
  2. Audience, Platform & Marketing Strategies
    • Who the game is for, what platforms you’re making it for and what sets your game apart that will make it marketable and different from others
  3. Core Gameplay & Mechanics
    • How the game is played including physics, rules and limitations
  4. Characters
    • What characters are in your game including what they look like, their names and backgrounds and personalities
  5. Story, Themes & Twists
    • If your game has an overarching story then you’ll outline your plot and how the game progresses with the story line
  6. World
    • Describe the world your game is set in, including maps and locations and their purpose or importance
  7. Assets
    • All the different images, music, animations, etc that you will need to have a fully functional game
  8. Technical Specs
    • What language you’re using, how games are loaded/saved, where games are stored, the number of servers you’ll need and anything else relating to the technical setup of your game
  9. Interface
    • What the game interface looks like and how the player will interact with it
  10. Outside References
    • Articles, links, design inspriations, or anything else that you’re using as a reference for the game you’re making
  11. Appendix
    • Code style guidelines, dictionary of terms, and anything else that is important for understanding your design document that may not necessarily relate to your game directly

Once you’ve fully fleshed out your game design by going into depth about the features, physics, economy, weapons, characters and how the game works it’s time to break it down. Start by creating lots of of small, easy tasks you can accomplish in order to see your core game mechanics to completion enough that you could play a simple version of your game without any extra bells and whistles. Set yourself up to do as little as you have to but as much as you need to in order to get a really simplified, yet completed, version of your game.

JS Tutorial: Recursive Promise Calls

Leave a comment Standard

The Reason

So in trying to help a co-worker I was looking for an example of how you can do recursive promise calls. To my surprise I didn’t find any soooo now you get this post 🙂 In a typical scenario you would chain your promises one after the other, however in real world situations the solution is not always so cut and paste. For instance you may need to ping a crappy device and wait for the results of the first ping to come back before you can ping the device again. If that’s the case upgrade your device, but if that’s not an option then you can always use this slash and hack solution of recursive promise calls which I would not recommend unless you have to but yeah, real life sucks sometimes. So here you have it, I hope this helps.

Test or fork the working example on Plunker

The Code

//somewhere to store the results of your recursive calls
var results = [];

* Recursive function
* @param int val how many times to call this function recursively
* @return null
var promiseMore = function(val) {
  console.log('attempting promise ' + val);

  //defer the promise
  var deferred = Promise.defer();

  //check your recursive conditions, keep looping while true
  if (val > 0) {
    //run your ajax request
      method: 'post',
      url: 'https://api.random.org/json-rpc/1/invoke',
      data: JSON.stringify({
        "jsonrpc": "2.0",
        "method": "generateSignedStrings",
        "params": {
          "apiKey": "4e69c4a7-4e47-4811-b110-6c7bfce079db",
          "n": 1,
          "length": 4,
          "characters": "abcdefghijklmnopqrstuvwxyz",
          "replacement": true
        "id": 29970
      dataType: 'json',
      success: function(response) {
        document.write('Got data for promise ' + val + '<br/>');

        //this triggers the recursion
        d = promiseMore(--val);

        //resolve this promise
        return deferred.resolve(d);
  } else {

* Whatever you want to do when your recursive promises are done firing
* @return null
* @print lots of BS random string results from our promises
var doSomethingWithResults = function() {

  document.write('Doing something with the results now...');

  //print out the data we got from the recursive promises
  for (i = 1; i <= results.length; i++) {
    document.write('Results ' + i + ': ' + results[i-1] + '<br/>');

//kick off the call to the recrusive promises