I’m always looking for ways to improve my javascript development and after a few weeks of playing, Javascript MVC test looks like it might be one the best tools yet.

We all know the power of testing our code.  A proper suite of unit tests can be among a projects most valuable assets.  They can ensure against the regressions rampant in rapid application development cycles that may not have adequate opportunities for proper QA.  Most importantly, when coupled with continuous integration tools, a comprehensive test suite catches many bugs close to when they are written and when they are easiest to correct.

Historically, testing javascript hasn’t been the most useful or productive of tasks.  The type of data manipulation, object inheritance and communication most conducive to unit testing has been minimized in most javascript applications.  Instead, most javascript is highly event driven and is often loosely tied to any specific server side data model.  Test MVC stands to provide a powerful testing framework for just those tasks we normally use javascript for.

Key Features

• Cross browser¹ support for typical DOM events, like keypress, click, submit, blur, and focus
• Simulate writing text or dragging an element
• Easily simulate AJAX functionality with sample data in fixture files

Firebug and its kin are awesome for debugging javascript, but once our scripts are in the wild we really don’t have any feedback of any kind about the state of the browser.  DamnIT from JupiterIT attempts to alleviate this by providing an automated feedback system for javascript applications.

How it works:

1. A box appears prompting you to describe your most recent actions:
2. One of the following occurs:
   • you type something and click send
   • you click “close”
   • 10 seconds pass with you doing nothing
3. DamnIT emails you the following information:
   • Browser
   • Page
   • HTML Content
   • Description (if you entered one)
   • Error message
   • File name, line number, and stack (if the browser supports them)

On the surface this is an incredible system.  In practice there are a few key issues that I think need addressed before the product is an ideal fit for every situation.  Basically, I have severe reservations about the email only nature of the system and its dependence on central management.  Both of these are key issues when dealing with sensitive information or large volumes of error messages and I’m sure will be addressed with future versions.  I am going to integrate the system into the next release of BLT and will be providing feedback from those efforts in the near future.  In the short term, you can check out DamnIT here:

https://damnit.jupiterit.com 

ParseInt is one of the handiest universal functions in javascript. Even though javascript’s ability to cast most any primitive to any other primitive on the fly is handy to say the least, sometimes we need to explicitly parse a string to make sure we have a legitimate number to work with.

ParseInt does this for us. What most developers don’t realize is that parseInt is base agnostic. While it typically assumes base ten, any base between 2 and 36 can be used and is indicated by the optional second argument.

Why is this a problem you might ask? Because octal numbers can be represented by a leading zero. In practice this can cause some interesting effects in your code.

For example:

var x = "010";

console.log( x );

console.log( x - 0 );

console.log( parseInt( x ) );

console.log( parseInt( x , 10 ) );

Returns:

"010"

10

8

10

Note: “010″ is equivalent to 10 in  “x – 0″!

If you don’t already know about Namespaces, Here’s a quick primer.

A namespace is a unique identifier for a particular library or collection of objects.  Namespaces are used to prevent conflicts between various libraries and to simplify debugging.

Traditionally Namespaces are defined using the unique name of a given project or library followed by a subsequent functional grouping i.e. (Yahoo.Util).  There is also a tradition from the Java community of defining namespaces & packages using reverse URL notation i.e. (com.ajaxbestiary.libraryname)  I’ve found this notation to be too cumbersome for most Ajax projects.

Abbreviating Namespaces 

Some developers prefer to abbreviate namespaces using a shorthand variable notation ie (var yu = Yahoo.Util).  This technique should be used quite carefully as it can lead to conflicts and confusion in multi-library & multi-person development.  My recommendation is that any abbreviations be standardized upon across all development within an organization.

Over the next few days I will be exploring the use of namespaces in common Ajax toolkits.

Here’s a handy jQuery plugin to speedup development and greatly enhance debugging.

http://happygiraffe.net/blog/archives/2007/09/26/jquery-logging 

This lets you simply add a .log command to a jquery chain and have the result logged to the firebug console with all relevant contextual information.  Fast, easy and simple.

IBM Developer Works has released an excellent article on AJAX interface development with a focus on best practices and a recomended work flow.

Check it out here:

http://www.ibm.com/developerworks/web/library/wa-aj-frontend/index.html?ca=drs-tp4207

Organizational standards are wonderful things.  They enforce consistency, help insure institutional competence and can dramatically reduce the learning curve to get additional staff up to speed on a project.  At the same time, in the world of AJAX standards can be too slow to adapt to a constantly changing landscape.  How do you strike a balance between flexibility and consistency?

Keep reading →