Moving the Blog!

Duct-tape_Moving_VanI’m moving the presentation tier from wordpress to Ghost.  I’ll leave the wordpress site up, but this will be my last post. I’ve migrated my existing posts over and future posts will be at presentationtier.com.

Why Ghost?

  • Its open source: I like that I can monkey around with it, and even add features for myself and fix bugs.
  • JavaScript and EmberJS based: Ember is my day job now, so I’m learning a ton about it, and I like the idea that I can quickly dive and and update the code.
  • Uses Markdown: I like writing in markdown and want to become even more comfortable with it.

Stay tuned on the new site for my next post. I intend to write up steps I took to move.

A Primer to Unit Testing for EmberJS

VaderUnitTestAs I’ve been learning Ember.js, I’ve been also learning about its unit testing approaches.   I’ve previously done TDD for UIs in Java, and then some in Jasmine as I’ve been trying to get back into JavaScript.  Ember’s default approach is slightly different, but I like it.  Here are some basics I went through to get a basic unit test environment up, enabling the development team I work on to test drive development in Ember.

QUnit

When you use Ember-CLI out of the box, it gives you a unit test and integration test setup around QUnit. QUnit is a simple, yet solid unit test framework, used and developed by the JQuery team.  Part of the QUnit setup gives you both a phantom JS and a Chrome test runner using Testem.  This allows you to run your tests either browserless by running “ember test”, or run both by giving the —server argument.   The great thing about running with the server argument is that testem will monitor your files and rerun the tests whenever it detects a change.

Ember QUnit Helpers

Ember provides several out of the box helpers that aid in unit testing Ember-specific objects.  Using the moduleFor helper method will load the appropriate ember object by name and prepare it for unit testing.  It also provides some conveinences around async testing that we’ll talk about next.  Running the implicit “subject” function will instantiate and initialize the given ember object under test, while the render object will attach it to the dom.  Once in the dom you have access to the JQuery object instance to exercise and run assertions on its state.
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('search-pane', {
    needs: ['component:chat-search-result']
});

test('it should hide an element on the component when myAction is sent', function(assert) {
    
    component = this.subject();

    component.send('myAction');

    assert.ok(this.$().find('.myComponentClass').hasClass('hide'));

});

Async considerations

Much of the flows in Ember (and web in general), have asynchronous aspects. Calls make ajax requests, or sometimes will use other asynchronous functions such as debounce, which will prevent a function from being called multiple times over a given time period.  You’ll often find that in your tests your assertions will be called before the actual function is finished executing.  Instead of forcing you to do things like setTimeout to wait to run assertions, which can be either unreliable or slow, Ember allows you to return an ember Promise from your testcase.  This promise can either be from the code (if your code being tested returns a promise, or a promise you create.  The below code returns a promise that uses the ember observer functionality to wait to run the assertions until the value we are asserting on is updated.
test('it should do blah blah blah in an asynchronous call', function(assert) {
    //setup test....

    var controller = this.subject();
    controller.send('loadHistoricChat', myArg);
    new Promise(function(resolve) {
        controller.addObserver('historyRoom', function() {
            resolve();
        }
    }.then(function() {
        //run my asserts...
    };
});

Spies, Stubs, and Mocks with ember-sinon

Ember has an add-on that will install the sinon.js library that gives you a nice api capable of mocking, spying and stubbing.  The spy object allows you to pass a function to your class under test and run assertions on how the class interacts with it. The stub object provides an easy way to fake out dependencies.  The mock objects let you specify expectations on how spies should be used, failing the test if not used as expected.  The below code builds on the previous example and creates a fake service object, where we are stubbing a couple of methods and asserting spies for others.
test('it should fetch historical messages based on a given chat search result', function(assert) {
    messages = [
        Ember.Object.create({body: "yo", name: "todd", date: "today"}),
        Ember.Object.create({body: "bro", name: "jo", date: "then"})
    ]
    activeRoom = {
        jid: 'abc'
    }
    historyRoom = {
        addHistoryMessages: sinon.spy()
    }
    chatService = Ember.Object.create({
        requestHistory: sinon.stub().returns(new Promise(function(resolve){resolve(messages)}),
        activeRoom: activeRoom,
        newRoom: sinon.stub().returns(historyRoom)
    });
    controller = this.subject({
        chatService: chatService
    });

    controller.send('loadHistoricChat', messages[0]);

    new Promise(function(resolve) {
        controller.addObserver('historyRoom', function() {
            resolve();
        }
    }).then(function() {
        assert.ok(chatService.requestHistory.calledWith(sinon.match({
            jid: 'abc'
        })));
        assert.ok(historyRoom.addHistoryMessages.calledWith(messages));
    };
});

Stubbing Ajax Calls

Often it is useful to test the interactions between your Ember components and the model, especially when you use the ember ember-data api.  In these cases you might want to simulate server responses from ajax calls.  There are a few options here.  If you want a quick method of mocking ajax for unit tests I’d recommend something like mockjax.  Mockjax provides a simple api for providing fake answers to specified jquery ajax calls.  Sinon also has a similar mechanism through its FakeXMLHttpRequest.  If you need something more elaborate for doing things like integration tests, I’d recommend ember-mirage.  Mirage is an ember add-on that provides a richly featured server stubbing library that runs client side.
Below is an example of a mockjax call to stub an http get.  Making this call will intercept the jquery xmlhttprequest and return the stubbed json:
$.mockjax({
    url: '/api/v2/search',
    contentType: 'application/json',
    status: 200,
    responseText: {
        res: results  //variable holding json response
    }
});

Code Coverage with Ember Blanket

The ember blanket add-on will add blanket.js execution to your tests, driven through the testem UI.  This will allow the developer to run tests with coverage and view the report.

Ember Pre-Push Hooks

If you want to add some added enforcement to keep your git remote branches clean, you can add the git pre-push hooks library to your project. It provides an easy way to run your linting and test cases when you perform a git push, failing the push if any testcase or lint fails.

The Ember.JS Firehose

121017-N-OR551-040  GULF OF ADEN (Oct. 17, 2012) Hull Maintenance Technician 3rd Class Jordan Crouse uses a fire hose on a simulated fire during a general quarters drill aboard the multipurpose amphibious assault ship USS Iwo Jima (LHD 7). Iwo Jima Amphibious Ready Group and embarked 24th Marine Expeditionary Unit (24th MEU) are deployed in support of maritime security operations and theater security cooperation efforts in the U.S. 5th Fleet area of responsibility. The U.S. Navy is reliable, flexible, and ready to respond worldwide on, above, and below the sea. Join the conversation on social media using #warfighting. (U.S. Navy photo by Mass Communication Specialist 2nd Class Morgan E. Dial/Released)

I’ve finished my first couple months at my new job at Interactive Intelligence.  Its been a lot of learning, a firehose if you will:-)  I’m working on an app built using Ember.JS, and learning that ecosystem has been both fun and time consuming.

Some impressions on what Ember has…

A Learning Curve

Ember’s a bit different coming from my previous Javascript experience working in Dojo, and then playing some in Angular.  It has quite a bit of structure to learn, and it actually polyfills javascript to enable its binding capability.    Learning the technology was a series of struggles to wrap my head around and get used to each of these aspects.  In addition, unit testing and build are different than I’m used to as well.  They have an ecosystem built around ember, all of which requires some learn’n.  Also the docs are a bit overwhelming at first.

A well done framework

So if you too are starting to look at Ember and are feeling a bit overwhelmed, don’t despair.  The plus side is I found that after struggling through most things once, i get it, and can actually see why its done and what it buys you.  The code you end up producing for it is pretty clean and modular, and you can get stuff done with surprisingly little code.  The other thing I’ve found is that its been improving a ton over the past year.  They are moving from a MVC approach to a more reusable component.  This is an approach that works well, and one that other libraries are using, such as React and Angular 2.  In fact the next major Ember release plans to include rendering in much the same way as React.

A Passionate community

One thing that’s really stuck out to me is how involved and passionate the ember community is.  The core committers are super engaged in the community via its super active Slack Channel and Forum.  There are also several podcasts where many of the passionate and influential community members discuss experiences, new features and add ons to EmberJS.  Development on the platform is super active.  Like I mentioned, there are lots of improvements and add-ons being developed.  There’s also a good article/talk discussing ember’s community activity vs its google trends that I think does the subject justice: http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-your-hype-fatigue.html

Plans this year as the hose dies down:

  • Contribute back code to the Ember community in some capacity this year
  • Present at a meetup (maybe the ember one)
  • Dive into its unit test and TDD capability: I feel like Ember has an interesting approach to web unit test, but as I do it I’m running into some challenges around async and the ember lifecycle.  I’d like to get a better understanding and work to make this a more engrained part of the team.
  • move this blog to Ghost – its an open source ember app!

A New Start

traveler

After about three and a half years at Deutsche Bank, this week I start a new job at Interactive Intelligence, working in its cloud platform and family of products.  Its great to be back at a tech company.   Especially one that’s doing really cool stuff with web technology, and that has a really innovative culture.  The bank was great to me while I was there.  I worked with some great people and we overcame some difficult challenges.  I got to a point where my passions in software development diverged from the work I was doing in my day job at the bank, and I knew it was time to take the next step.

The first thing I’m working on is an EmberJS application so I’m excited about diving in, not only to the ember ecosystem, but other concepts such as ES6 new CSS concepts like flexbox as well.  There are some really cool things about the culture of the team, such as participation in meetups, hackathons, and open source, all things I look forward to partaking in.

My side projects and goals are still on, though they’ve slowed considerably in the job transition of the last few weeks.  I’m looking at my habit forming reactJS app still, and plan to post here as it is made.

Right now I have a bit of a fire hose of info to learn and become proficient in, but its fun and challenging, just how I like it B-)

A Couple of Essentials for Your AngularJS Unit Testing Toolkit

Toolbox_icon_transparent_backgroundHere’s a couple of AngularJS features to help with unit testing controllers that I was able to take advantage of this past weekend.

Loading json test data from a file:

You can use the jasmine-jquery library for a simple api for loading json from a file (among other useful features.  For a controller, you can use as follows…
//you have to use "base" to address the root of your project
jasmine.getJSONFixtures().fixturesPath= 'base/data';
peopleData = getJSONFixture('people.json');

Simulating http response data with $httpBackend:

Once you have json data loaded, you will want to supply it to the $http process so that you can control the data that comes back.  You can do this through through the $httpBackend object
$httpBackend = $injector.get('$httpBackend'); 
$httpBackend.whenGET('/api/people').respond(200, peopleData);
or to simulate an error:
$httpBackend.whenGET('/api/people').respond(500, '');
and since the $http calls are asynchronous, you can simulate the server responding by calling:
$httpBackend.flush();
You can use these json file load and $httpBackend together to create a nice, easy way to stub json response data.

Further info for your reading enjoyment…

Anatomy of my MEAN App

anatomyOver the last couple of months, I’ve been working on an app using the MEAN stack to track strength over time. Ironically, I’ve been spending my after-hours time tinkering in JavaScript technology instead of exercising, so I’ve gotten a bit out of shape :-P

Before focusing on my next off-hour project, I’d like to give a rundown of some of the more interesting parts and lessons. I’ve posted some snippets, but you can see it all together on strength tracker’s github page.

First of all, here’s what it looks like:
StrengthTrackerFinal

Starting Quickly with Angular Seed

I used the github project angular-seed to get me going. It sets up the basic components you need to develop an angular app, such as jasmine and protractor for tests, and puts out some very basic components such as a directive (for showing version), and a couple of basic controllers that just show text that you can navigate between. Just clone the project, install the required dependencies with npm, and your are good to go.

For adding the rest of the stack (Mongo, Node, Express), I just used the express generator, which laid out the express directory structure and files to get a basic server running. I then copied my angular source tree into the “public” directory.

I played with mean.js, and used its yoeman generator to create a full stack skeleton, but I found that it gave me much of what I wanted to learn how to do myself, such as authentication with passport and connecting to mongo. Therefore I scrapped it for this project, though I think its a good option for getting started on a MEAN app quickly.

Authentication with PassportJS

I wanted to add some really base user registration and authentication, so I used PassportJS. Passport provides a plugin authentication architecture with some existing implementations such as basic userid/password, Twitter, and Google. While passport provides value by giving you multiple options for authentication, I’d pass on it in the future if I’m just doing local basic userid and password authentication. Most of the things I did in this stack ended up being fairly easy, but the couple of times I got hung up for an hour or 2 was with passport. I found 2 areas of difficulty.

First is that passport requires a specific order of loading its various parts interwoven within the larger node startup. If anything is out of order, then your authentication or server startup fails with unclear errors.

app.use order:

  • Express basics(express, cookie parser, bodyParsers)
  • session(with the right sauce)
  • passport(init and session)
  • authentication route(with passport strategy setup)
  • other routes

Express Setup with PassportJS – Order matters!

app.use(logger('dev'));
app.use(express.static(path.join(__dirname, 'public')));
app.use(cookieParser());
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: false }));
app.use(session({
  secret:"keyboard cat",
  resave:false,
  saveUninitialized:false,
  cookie: {
    maxAge: 60000
  }
}));

app.use(passport.initialize());
app.use(passport.session());
//the auth route includes passport strategy setup, which as to happen before
//other routes, and after passport initialization
app.use('/auth', auth(passport));
app.use('/exercises', exercises(passport));
app.use('/users',users(passport));

Secondly, I had some initial trouble interweaving the functions needed for session persistence of logins. To login using session persistence, you need to add deserialize and serialize methods. These will interplay with calls you make to the server and with your login.

  1. route handles login post, calls passport.authenticate
  2. authenticate calls the login strategy function you provide to determine if the user exists and can login given the submitted credentials
  3. callback given with the authenticate call is invoked, sending the appropriate response, 401 vs successful response and payload.
  4. user id is serialized into the session so future calls can be authenticated (until the user logs out or the session expires.
  5. the login function that passport attaches to the request gets invoked, user serialization call is invoked
  6. finally the function that you provide to the rest login gets invoked. If you see that the login is successful (assuming you’ve called the “done” function with the right stuff), then you can process that result and send the appropriate data / response code.

Here’s the code. Could be refactored to make thing’s clearer, but this gives you an idea of the complexity

router.post('/login', function(req, res, next) {
      passport.authenticate('local', function(err, user, info) {
        if (user) {
          req.logIn(user, function(err) {
            if (err) {
              throw err;
            }
            return res.json(user);
          });

        } else {
          res.sendStatus(401);
        }

      })(req, res, next);
  });

  router.post('/logout', function(req, res, next) {
    req.logout();
    return res.sendStatus(204);
  });

  passport.use(new LocalStrategy(
    function(userid, password, done) {
      db.collection('users').findOne({userid:userid, password:password}, function(err, result) {
        if(err) {
          throw err;
        }
        if (result) {
          done(null, result);
        } else {
          done(null, false);
        }
      });
    }
  ));

  passport.serializeUser(function(loggedInUser, done) {
    done(null, loggedInUser.userid);
  });

  passport.deserializeUser(function(id, done) {
    db.collection('users').findOne({userid:id}, function(err, result) {
      done(null, result);
    });
  });

End to End Angular Tests with Protractor

Protractor is an end to end testing framework that combines Jasmine and WebDriver. It operates similarly to cucumber, plus it has some AngularJS specific APIs. I was able to quickly get login functionality and some navigation and DOM verification working. I also created some data setup/teardown javascript objects so that users and workouts exist for the test and are cleaned up after.

The setup/teardown code was fun (in a geeky way). I created state objects for my two main data structures in the app: users and exercises. The state object simply takes a json object of whatever data I want to set up and implements database setup and teardown for that object:

var userState = function UserState(user, dbClient) {
  return {
    setup:function() {
      dbClient.insert('users', user, function(result) {
        console.log('inserted test user');
      });
    },
    teardown:function() {
      dbClient.remove('exercises', {userid:user.userid}, function(result) {
              dbClient.remove('users', {userid:user.userid}, function(result) {
                console.log('removed user %s, and all associated exercises', user.username);
              });
      });
    },
  };
};

Then at runtime, I call setup and teardown before and after the test/tests. In this case, I set up and tear down my user before and after all tests are run:

  beforeAll(function() {
    userState.setup();
    exerciseState.setup();
    browser.get('index.html');
  });
  afterAll(function() {
    userState.teardown();
  });

You can see it all together in my end to end tests directory.

Tight Feedback with Gulp and NodeMon

One thing I really enjoyed about getting back into the javascript ecosystem is how quick I got feedback on my changes. To avoid having to restart node when I made changes, I installed nodemon, a node server that will detect changes and restart itself. Additionally, I started using gulp to lint and execute unit tests as I make changes. It was extremely easy to set up a watch to look for code changes and run unit tests and lint immediately.

Here’s all the gulp code you need to get continuous linting with jshint and testing with karma:


gulp.task('lint', function() {
  return gulp.src(files).
    pipe(jshint()).
    pipe(jshint.reporter('jshint-stylish'), {verbose:true});
});

gulp.task('test', function(done) {
  karma.start({
    configFile: __dirname + '/karma.conf.js',
    singleRun:true
  }, done);
});

gulp.task('watch', function() {
  gulp.watch(files, ['lint', 'test']);
});

Easy Charts with Chartist

Chartist is a library build on top of D3. I saw a conference talk on it and it looked interesting, so I used it for my charting component. It already has an angular directive, so getting the charts to show up was just a matter of setting some simple json to the scope. It has databinding so the chart updates magically as you update values in the UI.

Styled Web Widgets with Angular Bootstrap

I wanted to use some bootstrap components, such as its alert box, dropdown and dialog box. I was able to leverage existing bootstrap angular directives.

Alerts

Alert

Modals

Modal

Dropdowns

Dropdown

Modular JUnit Behavior Tests

Over the years I’ve developed a way of doing unit tests in java that’s a bit different from folks I work with.  I’ve pieced it together from various books I’ve read on unit testing, and from from experience of writing a bunch of these.

I’ll walk through an simple example with FizzBuzz to show what I’m talking about, because explaining won’t do it justice.  Note:  This is necessarily not the optimal way of TDD for FizzBuzz.  I’ve used it just as a simple example for showing the pattern.

What I do is split the tests into the classic 3 step pattern of Arrange, Act, Assert, doing this with a given/when/then language.

I Arrange with a factory method

public FizzBuzzRunner givenAFizzBuzzCalculator() {
    return new FizzBuzzRunner(new FizzBuzzCalculator());
}

With more complicated setups, I’ll augment the factory method by having it take a builder pattern.  Then you can say things like

givenAFizzBuzzCalculator(withX(X).withY(Y).withZ(Z));

I Act with a runner class

private class FizzBuzzRunner {
    private final FuzzBuzzCalculator fizzBuzz;
    public FizzBuzzRunner(FizzBuzzCalculator fizzBuzz) {
             this.fizzBuzz = fizzBuzz;
    }

    public FizzBuzzVerifier whenFizzBuzzRunsFromTo(int from, int to)     {
         return new FizzBuzzVerifier(from, to);
    }
}

I Verify the result with a verifier class

private class FizzBuzzVerifier {
    private final List<String> fizzBuzzResult;
    public FizzBuzzVerifier(List<String> result) {
          this.fizzBuzzResult = result;
    }

    public void thenVerifyExpectedTextAtIndex(String expectedText, List<Integer> expectedIndices) {
          for(int i=0;i<expectedIndices.size();i++) {
               assertThat(fizzBuzzResult.get(i), is(equalTo(expectedText));
          }
    }

     public void thenVerifyIndexNumberTextAtIndex(List<Integer> expectedIndices) {
          for(int i=0;i<expectedIndices.size();i++) {
               assertThat(fizzBuzzResult.get(i), is(equalTo(String.valueOf(i));
          }
    }

}

I Daisy Chain the testcases

@Test public void
shouldReturnFizzOnMultiplesOfThree() {
    givenAFizzBuzzCalculator().
          whenFizzBuzzRunsFromTo(0, 30).
          thenVerifyExpectedTextAtIndex("Fizz", Arrays.asList(3, 6, 9, 12, 18, 21, 24, 27));
}

@Test public void
shouldReturnBuzzOnMultiplesOfFive() {
    givenAFizzBuzzCalculator().
          whenFizzBuzzRunsFromTo(0, 30).
          thenVerifyExpectedTextAtIndex("Buzz", Arrays.asList(5, 10, 20, 25));
}

@Test public void
shouldReturnFizzBuzzOnMultiplesOfFifteen() {
    givenAFizzBuzzCalculator().
          whenFizzBuzzRunsFromTo(0, 30).
          thenVerifyExpectedTextAtIndex("FizzBuzz", Arrays.asList(15, 30);
}

@Test public void
shouldReturnTheNumberOnNonMultiplesOfThreeOrFive() {
    givenAFizzBuzzCalculator().
          whenFizzBuzzRunsFromTo(0, 30).
          thenVerifyIndexNumberAtIndex(
             Arrays.asList(0,1,2,4,6,7,8,11,13,14,16,17,19,22,23,26,28,29));
}

I really like the approach because it has a few benefits…
  • Readability – The testcases themselves work as a DSL.  You can understand what the test is doing very easily.  It also breaks the code that runs the test into several objects, with like methods grouped together.
  • Reuse – Since my test logic is built into objects, I can reuse these for multiple tests.  I also try to write the execution methods in a way where I can pass in the variations in data.
  • Speed – Because the test lend themselves to more “DRY” programming, especially in more complicated scenarios, I’m writing less code.  Also, the objects follow a specific order, and each method returns the next object in the list.  This is awesome for command completion.  Imagine after typing your given method, you get a command complete menu of your “when” methods available.