2011 - Eric Feminella

Test Driven Javascript with QUnit

For the past year I have been using jQuery Mobile for developing web based mobile applications leveraging HTML5, CSS3 and JavaScript. Like all UI implementations, meaningful test coverage is essential to ensuring requirements have been met and refactoring can be achieved with confidence. Building applications for the Mobile Web is no different in this respect. And so, a high quality Unit Testing framework is as essential to the success of Mobile Web Applications as it is to their Desktop counterparts.

Why QUnit?

While there are quite a few good JavaScript Unit Testing Frameworks available, Jasmine in particular, I have found QUnit to best suit my particular needs for implementing Test Driven Development in JavaScript based on it’s clean design and practical implementation.

A Simple, Powerful API

The power of QUnit lies in it’s simple and a rather unique approach to Test Driven Development in JavaScript. The QUnit API introduces a few slightly different test implementation concepts when compared to the more traditional xUnit style of TDD. In doing so, QUnit succeeds in simplifying some of the tedium of writing tests by leveraging the language features of JavaScript as opposed to strictly adhering to the more traditional xUnit conventions, the design of which is based on an fundamentally different language idiom – that is, Java.

For example, consider the follow which tests for a custom data namespace attribute in jQuery Mobile:

test("Test expected namespace override", function() {

var expected = "someNamespace-";

var actual = $.mobile.ns;

equal(actual, expected, "expecting namespace to have been set.");

});

Figure 1 (run) (source)

The above test may appear quite straightforward, yet it serves as a good example by illustrating how each test in QUnit is implemented by the QUnit test fixture. The first argument is simply a String which describes the test case. This is quite convenient in that the intent of a particular test case can be expressed more naturally in textual form as opposed to using a long, descriptive test method name. The Second argument contains the actual test implementation itself, which is defined as an anonymous function and passed as an argument to QUnit.test.

As you may have also noticed from the above example, there are some, perhaps subtle, differences between the QUnit style of testing and the traditional xUnit style. Specifically, whereas in xUnit assertions expected values are specified first and preceded by actuals, in QUnit actuals are specified first followed by expected values. This may feel a bit odd at first however, after a few tests it’s easy to get used to. Additionally, where an assertion message is specified before any arguments in xUnit, in QUnit assertion messages are specified after all arguments. With regard to test descriptions, this is a difference I prefer as, a test message is always optional so passing this value last make sense. While somewhat subtle differences, these are worth noting.

A Complete Example

As code can typically convey much more information than any lengthy article could ever hope to achieve, I have provided a simple, yet complete, example which demonstrates a basic qUnit test implementation. (run) (source).

1 Comment

Tracking HTML5 Support in Chrome

Google has now made it easy to track the current implementation status of HTML5 in Chrome via The Chromium Projects’ new Web Platform Status page.

Many of the sections have links to their html5rocks site, which provide further details and more in-depth tutorials of implemented specifications.

The current sections include:

This is certainly something to keep an eye on as, Chrome is setting the standard in terms of HTML5 support by desktop browser vendors.

September 18, 2011 APIs / Browsers / CSS3 / HTML5 / JavaScript

Comments Off

HTML5 Elements: The <base> Tag

The HTML5 Specification introduces many new semantic elements, as well as specifications for existing elements; one of which is the <base> Tag, which allows for specifying a root URL from which all linkable elements in a document (hyperlinks, images etc.) are based, as well as a default target for all linkable elements.

Overview

The <base> Tag provides two attributes; href (Hyper-text Reference) and target, respectively, which have the same semantic meaning as that of a hyperlink.
Only a single <base> Tag is to be defined per page and, must be defined before any elements which except a URL are defined (other than the html element).

Note: While the <base> Tag is not new to HTML5, the changes to the a Tag implies a difference (albeit, marginal) as, a Tags are always hyperlinks, or placeholders for hyperlinks.

Example

Like all HTML markup, usage of the <base> Tag is easy and straightforward: Simply add a single <base> Tag in the <head> element of the document and define either a base URL and / or default target attribute.

Defining a default base URL and target:

<!DOCTYPE html>

<html>

<head>

</head>

<body>

<nav>

<a href="aboutus.php">About Us</a>

<a href="contactus.php">Contact Us</a>

</nav>

</body>

</html>

The above links will all default to a blank target (new page), with each link’s base URL defaulting to “http://somedomain/app”. Individual links can override the base URL as well as the default target.

Support

The <base> Tag is currently supported by all major browsers.

September 1, 2011 HTML5

Comments Off

Map Remote in Charles

Of the many Network Debuggers available, for years I have, and continue to find, Charles to be a choice Web Debugging Proxy by all standards. This is largely due to its capabilities and many useful features, some of which are a bit less obvious than others.

One such example is the Map Remote feature which allows for the mapping of local URLs to remote URLs. This can be extremely useful as it allows for testing against many different environments without the need to change URLs or Endpoints in code.

Map Remote

As the name implies, Map Remote allows for mapping requests made to a local resource to be forwarded (transparently) to a Remote resource. So, for example, a local service at http://localhost:8080/some-app/some-service could be mapped to a remote service at http://dev.somedomain/some-app/some-service via a simple configuration using Map Remote. Moreover, Map Remote can be configured to map an individual resource (such as the previous example), all resources within a sub directory, all resources in a domain, all resources in a local subdirectory to a completely different remote subdirectory or all resources for a given suffix.

To configure the mapping of a local resource to a remote resource, in Charles, from the Main Menu select:

Tools
Map Remote
Click “Enable Map Remote” from the Map Remote Dialog
Paste the Local resource URL in the top “Map From” section (Charles will parse and auto-fill the protocol, port etc. from the host value provided)
Paste the Remote resource URL in the bottom “Map To” section

Once completed you will see the mapping in the resulting dialog and the mappings will be made when using Charles until they are removed or the “Enable Map Remote” setting is turned off. Additional Mappings can be added following the same steps and existing mappings can be removed or edited by double clicking on them. The only improvement I would like to see added is the ability to “clone” an existing mapping so as to quickly configure a slightly different mapping without the need to start from scratch.

There is also a Map Local Feature in Charles which is essentially the inverse operation of Map Remote and can be quite useful as well.

If you regularly test against different environments and use Charles then I highly suggest trying Map Remote. For more information, check out the Charles Documentation.

August 22, 2011 News

Comments Off

The convergence of Mobile and Desktop UI Design

Successful User Experience and User Interface Designs are inherently intuitive and simple. Not necessarily simple in the “less is more” aspect alone; but rather in that the designs focus on essential tasks – and provide an experience which allows for completing those tasks easily and efficiently.

With this in mind it is not surprising that many modern Desktop UI Designs are being influenced by Smartphone UIs; for they, by necessity of constraint, address many design challenges which can be easily overlooked in Desktop UI Designs.

Both Apple and Microsoft have borrowed from their respective Mobile designs in their latest Desktop OS offerings; Lion and Windows 8.

Ultimately, I believe this convergence of the Mobile and Desktop paradigms will lead to better User Experiences. In fact, I have been leveraging many mobile concepts in Desktop UIs for some time now to much success.

July 4, 2011 Software Engineering / UX Design

4 Comments

Custom Search Engines in Chrome and Firefox

Recently I upgraded to a beautiful new iMac, on which I needed to configure my development environment and general workflow preferences. This required a few steps which I haven’t performed in quite some time and, upon doing so, I was reminded of how minor, yet useful many of these simple configurations actually are.

One such configuration involved defining Custom Search Engines in both Chrome and Firefox – a rather nice facility a colleague shared with me a while back. In case you haven’t used them before, Custom Search Engines allow for defining simple and complex search queries which can be easily invoked using a predefined keyword in the Address bar in Firefox or Omnibox in Chrome.

For instance, I use a Custom Search Engine with JIRA for quickly searching tickets, etc. Once set up, searching (by example of JIRA) is as simple as typing in my chosen keyword “t” (for ticket) and entering a ticket number, as can be seen below:

Custom Search Engine in Chrome

Likewise, in Firefox, typing my Custom Search Engine keyword for JIRA in the Address bar brings up the following prompt:

Custom Search Engine in Firefox

Defining a Custom Search Engine

Setting up your own Custom Search Engine is simple and straightforward. Doing so in Chrome can be accomplished as follows:

Select the Wrench Icon.
Under Preferences, select “Basics”.
In the Search Section, click on the “Manage Search Enginesâ€¦” button.
In the “Other Search Engines” Section, add the name of your Search Engine, your search Keyword and the URL of the site you will be using, appending %s to the end in place of the Query.
Once completed, enter the keyword into the Omnibox. You will see the the Name you choose for the Search Engine automatically added. Type a Query, hit Enter, and you are all set.

In Firefox creating a Custom Search Engine is accomplished by specifying a “keyword” when adding a bookmark and, appending the bookmarked URL with %s in place of the Query. This can be done as follows:

From the Menu Bar, select “Bookmarks”.
In the Menu Drop down, select “Show all Bookmarks”.
In the Bookmark Library Dialog, select a folder (e.g. Bookmarks Toolbar).
Click on the Gear Icon in the top left of the Dialog.
From the Drop down, select “New Bookmark…”
Enter the Name of your Bookmark/Custom Search Engine.
In the Location field, enter the URL of the site you will be searching, replacing the query with %s (use existing Search Engines entries as a reference if needed).
In the Keyword field, enter an arbitrary keyword of your choosing.
Click “Add”
Enter the keyword followed by your query in the Address Bar. You will see the Name you choose for the Search Engine automatically added in the History Dropdown. Hit Enter, and you are all set.

And thats basically all there is to it. Simple, quick and useful.

June 22, 2011 Browsers

4 Comments