michel gotta's posterous

Just a while ago I checked out QUnit. I fiddled around with it, wrote some simple tests and I thought, this could be very useful. When writing code you always add some new features into existing functionality and that's where the errors and regressions appear, especially when it gets complex.

As we know, unit testing is great for frameworks with a lot of different functions depending on each other (that's one reason the jQuery-team developed or uses QUnit for testing). But how about testing user interfaces or simulating user interaction on websites? On websites we sometimes use small bits of code responding to the interaction or the input of a user, for example hiding or toggling elements or dynamicaly change content. When we modify parts of the code we don't want to click every button to test if everything is responding normal.

There is one way to test parts of your interface without modifing your existing code (I don't know if this is the best way but it's one way to run tests in a simple way). 

1. Setup your test environment

When you download QUnit, it comes with a basic test environment we can use. It looks something like that:

[...]
<link rel="stylesheet" href="../qunit/qunit.css" type="text/css" media="screen">
<script type="text/javascript" src="../qunit/qunit.js"></script>
[...]
<h1 id="qunit-header">QUnit Test Suite</h1>
<h2 id="qunit-banner"></h2>
<div id="qunit-testrunner-toolbar"></div>
<h2 id="qunit-userAgent"></h2>
<ol id="qunit-tests"></ol>
<div id="qunit-fixture">test markup</div>
[...]

2. Modify the test envoironment for our use

First, I added jQuery to our test envoironment, mainly to use the DOM ready provided by jQuery. Second, I added an iframe where the interface/website we want to test is placed:

 [...]
<link rel="stylesheet" href="../qunit/qunit.css" type="text/css" media="screen">
 <!-- add jQuery for the testing environment -->
 <script type="text/javascript" src="jquery.js"></script>
 <script type="text/javascript" src="../qunit/qunit.js"></script>
 [...]
 <h1 id="qunit-header">QUnit Test Suite</h1>
 <h2 id="qunit-banner"></h2>
 <div id="qunit-testrunner-toolbar"></div>
 <h2 id="qunit-userAgent"></h2>
 <ol id="qunit-tests"></ol>
 <div id="qunit-fixture">test markup</div>
 
 [...]
 

3. Get the jQuery-Object from your original code

After the DOM ready we have two different jQuery objects in the browser. The one from the test environment and our original object in the iframe. To avoid any trouble we "cleanup" the standard $ object in our test environment and get a new jQuery object in noConflict mode named "$q" (for QUnit);

[...]
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="../qunit/qunit.js"></script>
<script type="text/javascript" charset="utf-8">
   $q = jQuery.noConflict(true), 
   $ = null,
   jQuery = null;
</script>
[...]

4. Get the "original" jQuery object

The next step is to get the jQuery object from the iframe to trigger events like clicks, hovers or submits in your interface. We can do this after the DOM ready of the test environment:

[...]
   <div id="qunit-fixture">test markup</div>
   
</body>
<script>
// on DOM ready
$q(function() {
   // fire event when iframe is ready
   $q('#testframe').load(function() {
      // Get the jQuery Object from the original code
      $ = window.frames[0].jQuery;
   });
});
[...]

5. Let's test

After the setup we can run a simple test. This is very basic...just an example.

 [...]
 // on DOM ready
 $q(function() {
   // fire event when iframe is ready
   $q('#testframe').load(function() {
      // Get the jQuery Object from the original code
      $ = window.frames[0].jQuery;
      test('check if dialog closes', 3, function() {
         // On start this is visible
         ok($('#dialog').is(':visible'));
         // Simulate a click
         $('#close-dialog').click();
         // Now #dialog should be hidden...
         ok(!$('#dialog').is(':visible'));
         // Click again
         $('#close-dialog').click();
         // #dialog should still be hidden...
         ok(!$('#dialog').is(':visible'));
      });
   });
 });
 [...]
 

Though, this example isn't very complex or logical but if we change (for some unknown reasons) our original code from: 

$('#close-dialog').click(function() { $('#dialog').hide(); });

to

$('#close-dialog').click(function() { $('#dialog').toggle(); });

our test will fail, because after the second click the dialog would be visible again.

Some other test checking the error validation of a ajax form could look like this:

test('check if form throws error on email validation', function() {
   // Write some invalid values to the email field
   $('form input#email').val('somewrong.email.com');
   // submit the form
   $('form').submit();
   // check if the input field gets an error
   ok($('input#email').hasClass('error'));
});
 

Conclusion

I don't know how complex the tests can get and I'm shure you can't test everything but this is one aproach to test interface functions and avoid regressions without clicking through your interface and checking every response. Of course, this is just for testing the code and the response of the interface and not the usability. (This stuff was just tested in Google Chrome, no warranty for other browsers)

Download example or check the the GitHub Repository

Note: Make sure you run this on a server (or your local server) otherwise you will have problems accessing the iframe via JavaScript.

UPDATE: 

• 2012/02/25: Added a download link with a "working demo" after Jesse Breuer made the proposal in the comments.

So, this is the first time I write about work I've done on my blog and I think the Smashing Magazine Web Design Challange is a great chance to do this and look at my own work with some critical thinking. The project I'm writing about is a website/blog I made for a friend some month ago. We know each other since we were 12...13 years old, and he always had the plan to become an actor. So after school he studied acting and he is about to finish his studies. So this website is kind of a portfolio to promote him and the projects he had done during the last years and I am supporting him with my webdesign and development skills.

Typography

We started with the typography and the logo. The font we seached had to be: characteristic but not intrusive, matching his appearance and personality, websafe and cheap. We both choose the Raleway by Matt McInerney wich perfectly matches the wiry and thin but highly characteristic impression he makes on stage.

The nice "fl" ligature makes the "florian mania" word mark even more characteristic and is used in the logo as well. Some self criticism: I sometimes think the logo is only working with the word mark. So the problem is, you always have to use it combined. 

Styling

This thin swissy black/white reserved styling, comes from the criteria we had on the typography and is ensuing from that point.

Grid

For building the layout I used a 24 column grid (by 960.gs) which fits on the landingpage with the 3 columns below the picture.

But on the contentpages, for my taste, the whitespace between content and the contact column on the right is to big. That's because I followed the grid to much. I think a better adjustment of the grid would have been good for the content pages.

Layout

I used a very clear and classical layout, with a navigation above the content. We don't have a very complex navigation structure, but one that could grow in the future. The contact informations are always visible and easy to find, if you want to offer him a job.

Imagery

The best thing was, I had a lot of good atmospheric pictures of him I could use. If you are a scout or into casting you search for a specific type of person or character and a picture (or a video) is the best way to transport that to this audience. The first thing you see when entering the page is this big box with pictures of the person, so you get this impression right away.

Color

I decided not to use much colors in the layout. The pictures are impressive enough, you don't need to much colorfulness around them. The orange I used for the links needed to be striking to catch the eye and be warm in contrast to the very calm base of the layout.

Some self criticism: When I criticize layouts of others, mostly I my suggestion is, "can we make it more colorful?".

Conclusion

I'm somehow out of the "designing business" for a while because I work as a front end developer since I graduated. But sometimes I am the one giving feedback to the designers and I am the one asking the questions. This project was like testing if I still can design a website and not just developing the code underneath the hood.

And now, you're pleased to comment and criticize!

Buckminster Fuller + Leonardo = ∆♥