When I worked at The Guardian, before committing code to Subversion, unit tests were run against the Java codebase. This is pretty standard. Sometimes, things slipped through and were caught at the Continuous Integration stage where an automated build would perform deeper tests and verify the code integrations of each developer hadn’t broken anything. This approach works extremely well.

When it came to the front-end, the only tests that were run was pushing JavaScript code through JSLint. This wasn’t set up as a pre-commit hook. Rather, it was up to the developer to execute a command-line script that performed these tests. I am in no way complaining about this. It was the first and only place I have worked that actually bothered to set up any formal testing of front-end code.

A few months ago I went to a presentation given by Neil Crosby at Skills Matter. Neil spoke about a project he has been working on that addresses the lack of automated frontend testing.

Most web developers will occassionally validate HTML and CSS, and put their JavaScript through JSLint. If this were automated, a lot of time would be saved. Some bugs can take hours to fix and in the end, for example, all that was missing was a closing span tag in the HTML.

Neil’s come up with a framework, called Frontend Test Suite, that automatically runs frontend code through the above tools. The suite is built in PHP and it is recommended that you install local copies of the HTML Validator, CSS Validator and JSLint so your IP doesn’t get banned.

I followed Neil’s installation steps in the file SETUP, which are briefly listed here:

1. Installed PHP (didn’t really because it’s already installed with Mac OS X 10.5.7
2. Installed PEAR
3. Installed PHPUnit
4. Downloaded Frontend Test Suite
5. Installed HTML Validator locally
6. Installed CSS Validator locally (thanks Jen)
7. Installed Rhino
8. Downloaded JSLint.js

I use Aptana regularly so, alongside the project I’m currently working on, I created a new project, dumped the Frontend Test Suite files into it and made the necessary edits to the example file. I execute the tests via the command line but at some point I will set up Aptana so I can execute it from there.

Next I need to workout how to get subversion to run these tests pre-commit.

---

Posted by Nick on May 29th, 2009 :: Filed under css,development,html,javascript

---

Today I thought I’d see how the website I’m currently front-end developing looks my phone’s browser, the G1. It was simple to view since the G1 has wi-fi so I typed in my laptop’s IP address followed by the path to the website. Renders great! Well it would, because the browser is based on Webkit.

There was one thing that irked me. The “print this page” link was present on the page.

The “print this page” link is inserted via JavaScript because JavaScript must be present in order to execute the window.print() function. Of course, I test for the presence of the function before inserting the link into the page, e.g. if(window.print) {…}.

So the browser is capable of printing but the device is not. For the most part users wouldn’t bother clicking on this link but still it feels wrong. I don’t know if the browser is aware of what device or operating system it is running on or if it knows of the device’s capabilities. I’m guessing that it doesn’t. In the case of the G1, the browser is based on Webkit and a fair bit of custom development has gone on. I don’t know if the JavaScript engine is tinkered with. If it is it would seem like an obvious thing to remove.

In a wider context, PPK touches on a similar topic in his blog post about testing mobile browsers. He says there’s a new class of browser compatibility errors: when browsers are unable to make full use of the device’s capabilities. I don’t know how to class what I have written about but I wouldn’t necessarily class it as a browser compatability error.

I’m sure more functions could be stripped from the JavaScript engine of a mobile device’s browser. The example above it pretty edge-case stuff but I expect as mobile browsing takes off these things will need fixing.

---

Posted by Nick on March 12th, 2009 :: Filed under javascript,mobile

---