One of the biggest hassles with web development is the lack of any real test harness. I have lamented about this before, especially when it comes to testing such ephemerals as an elements height, width, etc. So far the best tests I have run into are your two eyes, which is fine when you are working and testing on one discreet component... but web sites, especially the ones I work on, tend to be more then just 1 or two discreet components.

Enter Selenium IDE. The Selenium IDE provides you with a method to record and execute automated tests of your website. It is easy to use, and hella cool. It can test things like the existence of an element, the text contained inside of an element, its width, height, position, etc. Using selenium, you can build yourself unit tests. This is especially useful and powerful if you happen to be one of the unlucky bastards faced with writing code in JSTL, SMARTY, or some other templating-language-that-needs-to-die. Now you finally have unit tests.

Using Selenium, the testing process is a little more automated. More importantly, you can build a series of regression tests, to ensure the stability of your web application.

There is another piece of the web-development puzzle here, and that is the Moz Repl. An REPL is a Read Eval Print Loop, basically an interactive command interpreter that you can feed commands to, and experiment with. the Moz REPL is a javascript version, that lets you inspect and modify any Javascript object in the browser. This REPL is telnet enabled, in fact, there is even a way to make Emacs talk to this REPL, so you can poke around the browser from within your text editor. This is amazingly powerful in two regards:

1. you can script your browser from emacs
2. you can edit code inside emacs, and send it right to the javascript interpreter for testing, and evn install it on the current page

The existence of this REPL is what finally pushed me to stop using Jedit and move to using Emacs incedentally enough.

So the final piece of the puzzle is something I call Selenemacs. It is a global emacs minor mode, in conjunction with some simple javascript that will script selenium, and provide you with feedback on whether or not its tests pass or fail.

Update 2007-07-09: new versions (Version 0.2) added
Here are the two files:

• selenemacs.js
• selenemacs.el

Here is how you use them:
First, download the MozREPL and Selenium IDE extensions for firefox
Edit selenemacs.el to make sure that the variable selenemacs-js-file points to selenemacs.js
Enable the MozRepl (Tools->MozLab->StartREPL)
Load up selenemacs.el inside emacs (load-file "path/to/selenemacs.el") works
Enable the minor mode selenemacs-minor-mode
Record your test in SeleniumIDE
Use the emacs command selenemacs-execute-test to launch the test, its shortcut is C-c C-s C-e
Emacs tells you if the test passed or failed.

The idea here is that you write your test, and stop using your eyes to test the results of your coding to the browser, but instead use Selenium. This is especially good if you are doing multi-stage and repetitive like testing logins, searches, etc. You can code and test right inside emacs, and only have to switch to the browser to verify that your tests actually passed.

These files also show an interesting way to script mozilla through emacs. The next step of course is to get emacs to start interacting with Firebug.

I found this group of icons at the bottom of my Firefox status bar, and it pretty much sums up my thoughts. I've been using GreaseMonkey to help out the team here at work. Small, simple little scripts, that seem to have a huge effect. It's fun to write these little scripts, and it's fun to take on a more "Research and Development" capacity. Maybe one day they will pay me to do that full time. That would be awesome.

The Firebug extension for Firefox by Joe Hewitt just rocks. It is the culmination of a few different Firefox extensions: the Web Developer Tool Bar, the Dom Inspector, Viewed Rendered Source, and Venkmen (the Javascript debugger). Firebug borrows from these extensions and more, packages them up in a nice, tasty usable extension.

It has a Javascript debugger that lets you set arbitrary breakpoints; DOM inspector that not only lets you see the structure of your page, but also any styles and events on each node in the DOM tree; an AJAX console viewer so you can see the raw HTTP requests and responses; and a console, where you can see Javascript and CSS errors and type in arbitrary Javascript.

The inspector alone is worth the price of admission, it allows you to hover over elements on a page, and it will not only highlight the element on page, but also highlight the corresponding element in the rendered source, and show you not only the styles applied to it, but where it got those style rules from. This is probably the feature of firebug that I use the most, and it has made my job as a web developer infinitely easier.

It provides a host of great Javascript functions as well through a console object. Not only can you send it debug, info, warning, and error log messages (no more alert debugging, horray!) but you can send it assertions—great for design by contract.

I have noticed a few problems with it. Every once in a blue moon my browser seems to crash, which might be a fault of firebug. It really is a once-in-awhile issue, like 2-3 times a week after a period of heavy usage. Firebug also has some known issues with regards to viewing HTTP Requests and Responses. Synchronous requests cause it to fail, as well as documents that are XML (like XHTML, for instance). In actual fact, these are Firefox issues, and not Firebug issues, but there is a good chance these issues are being worked on.

Despite these problems, Firebug is a very usable, very cool extension. If you do any kind of web development, as a job, or as a hobby, it is well worth installing.

Techno Chocolate! (oon tsch oon tsch oon tsch... dooo do do do do do!)

I found a neat little surprise the other day. It appears that the Mozilla extension auto update feature is RESTful; I found this out through the use of LiveHTTPHeaders. Whenever you have an extension like Spellbound or Firebug, Firefox will call home to a server, and perform a version check, comparing your version with the latest version it has. It is not 100% RESTful, the biggest problem being that there is an end-point style URI (https://addons.mozilla.org/update/VersionCheck.php) with a query string (reqVersion=1&id=firebug@software.joehewitt.com...) ideally, the uri would be something like /update/VersionCheck.php/1/firebug.software.joehewitt.com/... giving each unique identifier its own space on the URI.

Beyond that however, it is very good use of HTTP, all the information needed is encapsulated in the request and is stateless. Really this shows that a lot of simple web services are either inherently RESTful, or are just a hop skip and jump away from being a true rest webservice.

This is the important thing about REST webservices. It is not that you need to conform to a "REST Standard", but instead you conform to the HTTP spec and end up, by design, following at least some of the REST constraints.

For reference (and the truly geeky) , here is the request and response:

Request

https://addons.mozilla.org/update/VersionCheck.php?reqVersion=1&id=firebug@software.joehewitt.com&version=0.4&maxAppVersion=3.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.5.0.3&appOS=WINNT&appABI=x86-msvc

GET /update/VersionCheck.php?reqVersion=1&id=firebug@software.joehewitt.com&version=0.4&maxAppVersion=3.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.5.0.3&appOS=WINNT&appABI=x86-msvc HTTP/1.1
Host: addons.mozilla.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en,en-us;q=0.7,ja;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: no-cache

Response

HTTP/1.x 200 OK
Content-Length: 939
Connection: close
Content-Type: text/xml; charset=utf-8

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#">

<RDF:Description about="urn:mozilla:extension:firebug@software.joehewitt.com">
    <em:updates>
        <RDF:Seq>
            <RDF:li resource="urn:mozilla:extension:firebug@software.joehewitt.com:0.4"/>
        </RDF:Seq>
    </em:updates>
</RDF:Description>

<RDF:Description about="urn:mozilla:extension:firebug@software.joehewitt.com:0.4">

    <em:version>0.4</em:version>
    <em:targetApplication>
        <RDF:Description>
            <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
            <em:minVersion>1.5</em:minVersion>
            <em:maxVersion>3.0</em:maxVersion>
            <em:updateLink>http://releases.mozilla.org/pub/mozilla.org/extensions/firebug/firebug-0.4-fx+fl.xpi</em:updateLink>

        </RDF:Description>
    </em:targetApplication>
</RDF:Description>

</RDF:RDF>

In case you haven't downloaded it, check out The Colorzilla extension for Firefox. Not only is it a groovy color picker, but it reproduces a large chunk of what I use both the web development tool bar and dom inspector for, in one really easy step. Just go download it.

Right click on it and change your status bar to something like "%hex%|%dist%|%element%|%dom-path%" and revel in the webdevy goodness.

Mmmm

Eyedropper Gooey Web Devy Goodness.

I've been working on the Basic, Digest and Wsse authenticators for Meditation (they'll be available in the upcoming version 0.6). I was having some problems with the digest authentication. It is particuarly difficult to debug digest authentication, especially if the authentication fails, because there could be a variety of reasons why things have gone pear shaped. Is your nonce screwey? have you got the header properly set up?

The simplest method I have found is to add a new response header (I used "X-Meditation-Debug") and in that header, output any needed debugging information. Then you can use the Live HTTP Headers firefox extension to inspect what is being passed on both the request and response. Along with the Web Developer extension to clear any existing HTTP authentication, this makes a powerful combo.

I think that the next version Lily will have an option to output X-Meditation-Debug headers at a particular level, say 0-5 for user levels (so application builders can debug their application) and 6-10 for internal debugging.

Just a quick note whilst I am mumbling about REST.

It appears that PUT and DELETE methods inside of a form are not supported by most browsers out there. Which makes sense, because the html specification says that the method should only be GET or POST.

So when building your RESTful application, you're stuck either using POST for everything (which isn't really that RESTful) or AJAX, because XmlHttpRequest does handle PUT and DELETE.