Archive for February, 2015|Monthly archive page

Babylon JS

Posted February 25, 2015
Filed under: Frameworks | Tags: , , ,
* Leave a comment

Can’t say I was impressed. I understand it is in JS and WebGL what Flash is to the browser. Not bad though for smaller, simpler animated projects.

Of the 3 examples on their site (http://www.babylonjs.com), Mansion did not run, Dino hunt was OK, but poorly designed (not Babylon’s fault!), Retail, lagged and would not work at times. I accessed them using Safari Version 8.0 (10600.1.25) on Mac OS X Yosemite 10.10, Intel Graphics Iris 1536 MB.

Looks like it still needs some work.

I believe the potential here is great as an alternative to Flash for new developers. However, when one considers the large established base of Flash developers, IMHO, it will be on the scale of years before we see wide-scale use. At best, for smaller animated projects, it’s not bad (like the Dino Hunt).

I’ll have to re-visit in a year and compare what I see then, with what I’ve written here. Reminder set.

Simple “Hello World” Javascript Test Driven Development (TDD) Example Using QUnit

Posted February 22, 2015
Filed under: Best Practices | Tags: , ,
* Leave a comment

I’ve been meaning to try out Javascript TDD. So, here goes.

Premise: We want to develop a simple Javascript object that will contain an ID and a Title. When developed, we will use it in our web page Index.html.

  1. Download QUnit from: http://qunitjs.com
  2. I placed the unit testing artifacts in their own folder.

    Figure 1 - Unit Test Folder Structure

    Figure 1 – Unit Test Folder Structure

  3. The bare minimum needed by QUnit in the TestJsTests.html file: 
    <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="utf-8" />
    <title>Javascript Unit Testing Using QUnit</title>
    <link href="../qUnit/qunit-1.17.1.css" rel="stylesheet" />
</head>
<body>
    <div id="qunit"></div>
    <div id="qunit-fixture"></div>
    <script src="../qUnit/qunit-1.17.1.js"></script>
    <script src="TestJsTests.js"></script>
</body>
</html>
  4. Time to setup the test we know will fail. Adding code to TestJsTests.js. The idea is to define a class “Greeting” with two properties: “Id”, and “Title”.  We will write our initial test, as if the class with these properties exists.  
    /// <reference path="../qUnit/qunit-1.17.1.js" /> 
/* globals QUnit, Greeting */
QUnit.test('Greeting Test', function(assert) {
    'use strict';

    assert.expect(2);

    var x = Greeting(1, 'Hello World');

    assert.ok(x.Id === 1, 'Id property passed!');
    assert.deepEqual(x.Title, 'Hello World', 'Title property passed!');
});
  5. As expected, the tests fail. (Note: there seems to be a layout bug in QUnit as we have a bit of runoff indicated by the blue arrow). This is good, we want it to fail so we can have a developer write the barest of minimum Javascript code needed to make the unit tests pass.

    First unit test

    First Unit Test

  6. Proceeding with developing Greeting.js.

    Greeting.js folder structure

    Greeting.js folder structure.

  7. Code for Greeting.js. 
    /* exported Greeting */
var Greeting = (function () {
    'use strict';
    var p = function (id, title) {
        this.Id = id;
        this.Title = title;
    };

    return p;
})();
  8. Updating the TestJsTests.html to include the Greeting.js code. 
    <body>
    <div id="qunit"></div>
    <div id="qunit-fixture"></div>
    <script src="../qUnit/qunit-1.17.1.js"></script>
    <script src="../Scripts/Library/Greeting.js"></script>
    <script src="TestJsTests.js"></script>
</body>
  9. And the unit tests pass!

    Unit Testing Passes

    Unit Testing Passes.

  10. In conclusion, we can now be confident that the code developed in Greeting.js is indeed good. With available unit test for our JS code, we can also confidently refactor our code. As the scope of the project grows, we can expand further on the behaviors expected of the code by writing further tests asserting the expected behavior. This can be valuable to the developers, as they can confidently develop code that causes the unit tests to pass.