assert(page.myButton).hasClassName('.disabled', 'Should be disabled');

The above example is simply the result of a false assumption that the CSS classname represents a contract of state for that button. CSS classnames should never be used as a contract between UI and test, they’re not and should not be coupled to functionality because (more often than not) visual design is changed more than functionality. The only way to test if a button is disabled, is to click it and assert that nothing happened. This of course is just a functional test of the UI, it won’t tell you if the button is hidden or the wrong colour.

click(page.myButton);
assert(page.myReceipt).doesnot.containText('Action complete', 'Should not have completed action');

In the snippet above the page elements are probably defined using a CSS or XPATH selector, this implies that there is still a contract between the tests and the UI. Let’s say page.myButton is defined with the following CSS selector 'div.popupbox .footer > button'. By using this selector you are assuming that the button in question will always be inside a div element with a classname of ‘popupbox’, the button will always live inside a footer, the button will always be … a button, not a link, you sure about that? Coupling your tests to markup and styling will lead to incredibly fragile tests, especially in an environment where UI design is constantly iterated upon.

To overcome this fragility, rather than assume a contact, define a contract. Creating a consistant vocabulary for element hooks for testing is quite easy. At Huddle we’ve defined a contract using data attributes in the markup, the CSS3 selector for the disabled button could look like this '[data-automation=submit-comment-button]', note that the intent of the button is used for naming, not the style. Decorating code like this makes markup a little messier but gives an immediate prompt to a future developer that this page is under test while also giving them the freedom to change styling without having to update and fix tests. Of course you can make up a contract that bests suits you and your team, perhaps web-aria attributes might be better?

But what about contracts for visual testing, couldn’t we just agree that '[data-automation=disabled]' means that the button is visually disabled? No, it just doesn’t work. You’ve given some protection to the CSS developer that’s re-skinning the UI but you have no guarantee that the styling won’t have broke, nor that clicking the button doesn’t submit the form. You have to simulate the user, it’s the only reliably way to test UI.

In a future post I will discuss how visual regression testing is possible.

I’ve posted before no how to use JSTD for unit testing JavaScript.  Unit level test coverage encourages better design and supports refactoring through fast  feedback.  It really does make a difference to code confidence and although I personally do minimal TDD, writing tests as you go can help massively in understanding problems and fleshing out solutions.

Awesome, great for logical code but… I have found that unit tests for behavioural UI code provide little in the way of qualitative feedback and TDD can actually hinder UI problem solving by abstracting the developer away from the real problem they’re trying to solve, the UX problem.

So given the lack of total coverage with unit tests its understandable that we’d want to build functional UI tests as well.  The most popular tool for that would be Selenium, a tool for automating web browsers.  Selenium is useful for integration testing, that is, end-to-end, make sure the website/webapp works completely in its entirety. But Selenium is slow, super slow; especially with web applications where you need to set up real data for each test.  Fine for integrated testing, not fine for functional UI testing. Integration and UI testing are different things and should be done separately.

There is of course a new kid in town. PhantomJS attracted me for two reasons.  The first being that it’s a headless browser, so runs from the command line and is really quick. The second is that it lets us easily interact with web pages using JavaScript (crazy idea, who came up with that?).

PhantomJS by itself is pretty raw, I decided to use it with the CasperJS library to help build up navigation scenarios. CasperJS gives us all the cool test assertion stuff as well as handy methods for finding elements and raising DOM events.  Now here’s the clever bit. Sinon.JS provides an XHR mocking interface, it can block all XHR requests and let you respond to these requests with fake data.  By injecting Sinon.JS on to the page at the beginning of a test suite not only can we isolate the UI from the back-end API, but we can drive the UI with fake data and even make assertions on outgoing requests.

Below I’ve drafted a small example of what I mean (It doesn’t work, but represents a simpler implementation of what I have already built). CasperJSs page.initialized event is very useful for setting up XHR mocks early on, before any window.onload API calls are made.

casper.
start(rootUrl).
addListener('page.initialized', function(){
  casper.page.injectJs( libs+'/sinon.js' );
  casper.evaluate(funciton(){
    window._xhr = sinon.useFakeXMLHttpRequest();
    window._requests = {};

    window._xhr.onCreate = function (xhr) {
      var headers, body;

      if(request.method === 'GET'){

        headers = { "Content-Type": "application/json" };
        body = '[{ "id": 12, "comment": "Faking it is fun!" }]';

        // fake some data to make the UI do something
        xhr.respond(200, headers, body); 
      } else {

        window._requests[xhr.url] = true;
      }
    };
  });
}).
thenOpen(pageUrl, function(){
  casper.click('#my-button'); // trigger some ajax
}).
then(function(){
  var request = casper.evaluate(function(){
    return window._requests;
  });

  // test the HTTP interface
  casper.test.assert( request[posturi] === true, 'Should have posted a request'); 

  // test the User interface
  casper.test.assertTextExists('Faking it is fun!', 'Should have the fake comment in the UI');

});
// ...

Setting up Fake Ajax responses this way is a little clumsy, the solution I built at work abstracted this code away so that in the tests we only call a fakeResponse method and a assertRequest method. PhantomJS in general is very hackable, really easy to extend.

I’ve evangelised this approach to testing in my workspace and we have now fully adopted automated, isolated UI testing using these technologies. An unexpected side effect of faster feedback from automated UI testing is that we write fewer unit tests. If the feedback time is quick, may as well push as much of the testing to the front as possible. We still write unit tests for complicated logic driven JS components but get the bulk of coverage from the UI tests. There’s a balance obviously but this inevitably means less test duplication but better coverage. Oh and of course we still have Web integration tests (using Selenium) but write far fewer, tests aimed purely at end-to-end connectivity not functional UI.

So we now have fast, smart, flexible test coverage over our JavaScript application. Writing UI tests is no longer a burden. To quote one of my colleagues: “UI testing is fun again!”.

Grumble.js

Grumble.js came from a project at work (Huddle). I was given a fairly unreasonable specification: round speech-bubble like tool-tips that can be positioned at many angles, appear in multiple colours, be animated in sequence, contain translatable/localised text and work in every browser from IE6 to the latest Firefox.

The original project took me alone, about fifteen days. After I started I quickly decided not to use SVG/VML in favour of using background images, CSS3 and IE filters. I wanted to build it as a jQuery plugin because it was a good pattern, and patterns are better than no patterns. I learnt a huge amount about CSS3 and calculating axis, and was amazed by what could be done in IE6 with filters.

Originally I had no intention to open-source Grumble.js. But I thought I had built a solid piece of code that other people could use. When Huddle introduced ‘Tuesday time’/opensource day I decided to push the code to Github with a demo page, about a week later I posted links to it from Hacker News and Digg.

Purely out of interest I hooked up Google Analytics. Grumble.js was hugely popular with lots of coverage from blogs from around the world.  It’s documentation page has received over fifty thousand visits.

CoDesign.js

There was so much noise and excitement about the real-time web when NodeJS came out that I had to have a play.  So one lazy Sunday I used NodeJS and Socket.IO to build a real-time chat application. Was nothing fancy but it was easy enough to make me think that I could build a real-time drawing application.

CoDesign.js was the client-side implementation of this drawing application, and it wasn’t simple, and still isn’t finished.

Simple real-time drawing is quite easy, you simply push colour and x  y coordinates to the server to be broadcasted to the other clients; but complex image effects are far too large to push down the wire pixel by pixel. I learnt that the only way to make real-time drawing plausible is through the encapsulation of commands i.e. an instruction to use the ‘spray’ brush at x & y.  The processing has to be done on every client rather than sending a dataUrl encoded image for example.

Rather than building a functional set of features I was more interested in building fancy colour schemes and weird brushes.  I wanted to do what Mr Doob had done with Harmony, but in a way that would allow real-time collaboration on the creation of images. I’ve learnt a lot about working with HTML5 Canvas, JS performance and real-time web apps from this project. Oh and there’s a lot of maths in there, at least now I know about Sine waves!

Other than for the things I learnt, CoDesign.js was successful in that It’s awesome, and exciting to use. I just wish I had the momentum and ideas to make it truly notable.

Artify.js

The latest project, and as of writing this blog, unpublicised. Artify.js was a great little project, It took about a day to build.  I learnt about the HTML file API, drag/drop events and image analysis.  I also decided to play with Twitter’s Bootstrap for the first time to help build the documentation page.  It’s a nice little plugin that converts images into art with CSS3, and because the output of the plugin is just a bunch on DOM elements it’s really easy to style and ‘artify’ as you want.

All in all I think for the purpose of learning Artify.js has been my most successful project to date.  Unlike the other two, it’s not that useful but I learnt a load in just one day. I’ll certainly be looking to do more smaller projects from now on, so long as I get to learn something.

Asynchronous non blocking UIs do not wait, they lie. If there was no such thing as HTTP latency and un-performant databases then there would be no need to lie. Waiting might be the safest thing to do but it will slow down the user, distract them, frustrate them; and for what? Most of the time there is no need, we have all the data we need to show them what they expect to see.

Lying only works if it’s rare. No one likes a liar but everyone lies every now and again, right? We accept this in our relationships with people, and I think it is also true to say that we accept this in our relationships with web applications. No one likes big lies, but small lies are more acceptable.

So, we need a reliable back-end system so we don’t have to lie too much. And then we need to break down user tasks so that if we do lie it’s not about the loss of their freshly typed fifty page document.

Of course, to lie we must first know what the user expects to see. With regard to single page web apps: the client JavaScript application must be able to build new HTML; and as we’re building views on the client we’ll probably want our data as JSON from the server. Let’s assume we’re using an MV* framework like KnockoutJS or BackboneJS. JSON is retrieved from the server, the controller updates the model, the view updates with data from the model. When the UI lies, the model is populated directly from data collected from user input. If some data isn’t available then the UI can either fudge the data (maybe the user won’t notice?) or more honestly, extract data from a pre-made cache.

The lie must be convincing. Start getting data as soon as you think you’ll need it, behind the scenes. Create a cache that contains everything you’ll need. Use persistent browser cache when possible, not all data changes frequently. Inversely, request updates from the server API regularly for more changeable data – and don’t let the user know you’re doing it.

You can’t always lie. Needless to say if the user wants to upload a file off-line, they can’t, they know they can’t so we shouldn’t pretend they have. But a non-blocking UI shouldn’t stop them from queuing an action for when they do become online. Feedback is really important, with a file upload for example we could just tell them that the upload will happen later. File upload is actually an interesting case because the multi-part request is probably going to be long running and comparatively fragile. It’s a good idea in this case to let them know that something is happening in the background and listen for a window unload event to let them know their request will not be completed.

The interesting thing about building UIs that lie is that it enforces an architecture where the client has to fend for itself without server support, i.e. the client can work off-line. But also, by separating the concerns of API request handling and view state management it becomes easy to extend the data access layer to use other transport mediums such as web sockets or JSONP. Better composition also means easier automated testing.

Although there are architectural benefits to building asynchronous UIs, the main driver for such an approach is UX. The user really doesn’t care what the software has to do, they just want to complete their task and move on to the next one. Asynchronous UIs help support user workflows, but to make asynchronous UIs work we have to lie and I think this is wholly acceptable and something that we as users have already begun to accept.

var obj = {
  foo: 'bar'
};

with( obj ){
  console.log(foo); // bar
  foo = 'something';
}

console.log(obj.foo) // something

The above example shows how we can access and assign properties on the object as if they were variables in the local scope.

As you can see in the below example, the scope chain is the same as if it were a function closure.

var foo = 1,
    bar = 2,
    obj = {
      foo: 3
    };

with( obj ){
  console.log(foo); // 3
  console.log(bar); // 2
}

console.log(foo); // 1

Within the scope of a with statement the ‘this’ keyword will still refer to the parent object.

var obj = {
  foo: 'bar'
};

with( obj ){
  this.foo = 'boofar';
}

console.log(obj.foo) // bar
console.log(this.foo) // boofar

So why might you use the with statement? Generally you wouldn’t, it’s a little confusing to read, and doesn’t scale well with larger blocks of code. Douglas Crockford considers with to be harmful, though stackoverflow does offer a legitimate use for with.

In the example below the variable ‘bart’ is defined in both the outer scope and the inner scope of the method ‘say’.

var bart = 'cowabunga';

var say = function(){
  if (bart == 'cowabunga') return bart;
  var bart = 'ay caramba';
  return bart;
}

console.log(say()); // 'ay caramba'
}

Because the variable ‘bart’ gets hoisted, when the ‘say’ method is executed ‘bart’ is undefined. ‘ay caramba’ will be logged. We can fix this code by removing the ‘var’ statement in front of the second ‘bart’ declaration.

Hoisting also affects function declarations. As you might expect the following example fails, ‘bartSay’ is not defined.

console.log(bartSay());

var bartSay = function(){
  return 'cowabunga';
}

However if bartSay was defined in another way hoisting will come into play. Below I have defined ‘bartSay’ as a ‘named’ function rather than assigning an anonymous function to a variable called ‘bartSay’. Because there is no assignment the function gets hoisted intact.

(function(){
  console.log(bartSay());

  function bartSay(){
    return 'cowabunga';
  }
})();

The code below however, will fail. Despite sharing the same global object, each script block creates a new execution context. More here.

<script type="text/javascript">
  console.log(bartSay());
</script>

<script type="text/javascript">
  function bartSay(){
    return 'eat my shorts'
  };
</script>

A pattern for avoiding issues caused by hoisting is described in Stoyan Stefanov excellent book JavaScript Patterns. The ‘single var’ pattern is the use of a single ‘var’ statement at the top of a function, using commas for assigning multiple variables.

function(){
  var bart = 'eat my shorts',
      homer = 'hmm, doughnut',
      say = function(){};
}

My main problem with CSS is that it’s a markup language with added inheritance. “DAMN YOU CASCADE!!”, I’ve screamed this so many times at work. I spend far too much time fighting legacy code, the cost of re-factoring would be significant so I add another !important or add an ID to the selector. Constantly overriding is a bad smell. CSS doesn’t scale without being explicit.

There is a big mental shift when moving from CSS to SASS. Thinking of things as modules helps.

.clickable {
  color: blue;
  &:hover {
    color: red;
    }
  .ie & {
    padding-left: 1px; //some pretend box-model hack for IE
    }
  }

The above example uses the SCSS style. Note the use of the ampersand character to denote ‘this’. SASS allows us to encapsulate state and behaviours within a module in pretty much the same logical way that I would approach a JavaScript module.

Reuse can be achieved with variables, and inheritance patterns using @extend or @include.

$column-width: 256px;

@mixin astract {
  white-space: nowrap;
  overflow: hidden;
  width: $column-width;
  }

.clickable {
  @include abstract;
  color: blue;
  &:hover {
    color: red;
    }
  .ie & {
    padding-left: 1px; //some pretend box-model hack for IE
    }
  }

.special-clickable {
  @extend .clickable;
  border: 1px solid: blue;
  }

I love that we can achieve DRY code in this way. Sure you can extend style modules in CSS, but the relationships are defined explicitly in the HTML not in the stylesheet. This is a massive discoverability problem. SASS allows us to define these relationships in one place.

This is one way of achieving the same thing in CSS. Note that I’m also providing a HTML example.

.clickable {
  white-space: nowrap;
  overflow: hidden;
  width: 256px;
  color: blue;
  }
  .clickable:hover {
    color: red;
    }
  .ie .clickable {
    padding-left: 1px; //some pretend box-model hack for IE
    }

.special-clickable {
  border: 1px solid: blue;
  }

<button class="clickable special-clickable">click me</button>

As I mentioned earlier, there is a downside to using SASS, it compiles to CSS. It produces CSS without the same level of code re-use that you might strive to achieve yourself. SASS is lazy, especially where mixins are used. Generated CSS becomes bloated quickly, load time of the web page increases.

As with so much in our Industry, it’s a trade off. SASS is genuinely a more managable and enjoyable way to style the UI. But as a tool for building CSS? It’s as good as it can be, which isn’t quite good enough. The CSS bloat issue only begins to appear on larger UI’s, is that ok? I guess that depends on how bandwidth sensitive your users are. And selector performance? I haven’t noticed any problems though stylistically I would say that SASS encourages deep nesting of selectors which may be an issue.

In this day and age modern web browsers and network infrastructures can easily absorb the extra weight. CSS file sizes generated from SASS are in no way comparable to the files sizes you might expect from many JS libraries. And CSS selector performance is barely worth monitoring to be honest (Unless your users use IE6).

I’d recommend you have a play with SASS if you haven’t already, but you’re going to have to let go of some of your CSS sensibilities before you begin to enjoy it.

They can be used for defining private variables, and storing variables outside of a functions life-cycle.

JavaScript has function-level scope only, so unlike other C languages a ‘for’ or ‘if’ block won’t hold scope.

for (var homer in ['doh!','ray','mee']) {
// do something with homer
}

console.log(homer); // logs 'mee'

var homer = 'hmmmm donuts';
if(true){
var homer = 'doh!';
// other code
}
console.log(homer); // logs 'doh!'

To create scope within the if block we could do the following:

var homer = 'hmmmm donuts';
if(true){
(function(){
var homer = 'doh!';
// other code
}());
}
console.log(homer); // 'hmmmm donuts'

But generally it’s not good practice to reuse variable names for different purposes.

In the global scope, variables resolve to the global object ‘window’. ‘this’ in a global function will be the global object, but variables defined within that function wont resolve to the global object. Functions have there own activation object.

function(){
var homer = 'woo hoo';

var myobject = {
homer: 'spiderpig, spiderpig...',
say: function(){
console.log(homer);
console.log(this.homer);
}
}
myobject.say();
}

From this example we first log ‘woo hoo’ from current function scope then ‘spiderpig, spiderpig…’ as defined on the object.

The containing function is instantiated with the ‘new’ keyword

var me = this;
function Test(){
	console.log(this === me);
}
var myTest = new Test();  // false

Or.. The function is called on an owner object.

var obj = {
myFunc: function(){
return this;
}
};
console.log( this === obj.myFunc() ); // false

Take this example, what do you think will be logged?

var i = {
myvar: 'something',
invoke: function(callback){
callback();
}
};

var obj1 = {
myvar: 'default',
counter: function(){
if(!this.myvar){
this.myvar = 'foobar';
}
console.log(this.myvar);
}
}

i.invoke(obj1.counter);

Answer: ‘foobar’ gets logged.

‘this’ gets defined when the activation object is created for the current execution. The function reference is executed without an owner object so this will resolve to the global object;

What’s worse about this is that window now has a new property called myvar.

To complicate matters further you can explicitly define ‘this’. Either by (re)assigning the method to the desired owner method or by using the call and apply methods.

i.counter = obj.counter;
i.counter() // 'something'

obj1.counter.call(i); // 'something'
obj1.counter.apply(i, []); // 'something'

They are basically the same method except that apply() will let you pass in the arguments object (or an array of arguments).

• Lexical Environment
• Variable Environment
• This binding

The scope chain represents an array of parent ‘Variable environments’ up to and including the global variable environment.

Each Variable environment is in fact an object called an activation (or variable) object. Though not a real object in the normal sense, it does have properties which can be accessed.

{
__parent__ :[Object reference],
arguments: [Lots of fun that I wont go into now]
this: [Object reference]
mylocalVar: [undefined]
}

The above example represents the activation object after the initialisation of the current context, the myLocalVar property is a local variable.  At this point the activation object is sometimes referred to as the Variable object, as far as I understand they are essentially the same thing (if for the moment we pretend the with() method doesn’t exist).

The ‘this’ property  refers to the owner object (by default this is the global object .i.e. window).

The __parent__ property is a reference to the parent activation object. This object is not explicitly accessible, though access to properties on this object are implied from the scope chain.

The global context is some what confused, ‘this’ resolves to the activation object itself thus…

var foo = 'bar'
console.log(window.foo); // bar
console.log(this.foo); // bar