While the server-side method has not gotten much more advanced, the client-side methods are generations beyond where we used to be. Responsive Web Design and Adaptive Web Design provide the methods to use CSS and javascript to produce site that scales and progressively enhances to meet the end users device capabilities.

A couple months ago I decided to redesign my personal website again, with the goal of making it provide a good experience at mobile phone, tablet, and monitor sizes. Here's how I did it.

The Screen Sizes

I decided to focus on screen sizes starting at mobile phone (480px or less) all the way up to large browser (more than 1240px). Each resolution would be usable and contain a similar palette and graphical elements. I also attempted to minimize the amount of extra elements I load at the smaller sizes, assuming that these smaller sizes would have less (and more costly) bandwidth.

These are the layouts I ended up with:

As the available screen real estate gets larger, the logo size increases, the number of social icons increase, and additional inner right sidebar appears, and then finally additional background and an outer right sidebar become available. The width of the available reading area scales smoothly from the smallest size to the largest size.

Implementation

While my site doesn't have a lot of functionality, achieving the layout changes and addition of features at the largest sizes was still a nice challenge. The key to the site is the CSS media queries that alter the visibility of elements and areas, combined with some javascript to load in larger images or additional elements when relevant. In the event that a browser doesn't support media queries and javascript, they will receive the smallest possible layout. Though there are workarounds, I purposefully left the IE8/IE7 layout in this mode, which would also be used for most mobile browsers.

If you load the site in the secondary window and drag the width around, you will be able to see the transitions: http://tiernok.com

Images

I cheated a bit on images. Any image with the "imglow" CSS class will be hidden above 480 px screen width and replaced with ones that with a class "imghi". Since many small browsers would load the large image even if it is hidden, I put the actual image source in a data attribute and use a bit of javascript to populate the src value.


<img src="_n_images/logo_sm.png" alt="Eli Weinstock-Herman | Tarwn" border="0" class="imglow" />
<img data-fullsrc="_n_images/logo.png" alt="Eli Weinstock-Herman | Tarwn" border="0" class="imghi" />


The social images at the top of the screen have classes that define whether they are available for small resolution or not and display at half resolution in smaller screens. These don't load dynamically at larger size, so all 4 will load on browsers that load hidden images.

The background coffee spills start to show at the medium resolutions via positioned background images on the main content wrapper, so these only load when the screen is large enough to display them. This is also when the inner right side panel is displayed, along with the contact image and books. This content is loaded and not displayed at smaller resolutions, so there is some room to shrink that initial mobile load further.

CSS Media Queries

The main CSS logic is as follows:

> 480 pixels wide:

• Hide the small logo, show the large one at reduced size
• Increase the size of the 2 social icons in the header
• Switch navigation from bar to buttons, show more links
• Switch from full screen to fixed borders for main content

> 650 pixels wide:

• Show the large logo at larger size
• Show all 4 social icons
• Add last two links to navigation

> 750 pixels wide:

• Show the large logo at largest size
• Show inner right sidebar
• Constrain main body to 800px wide
• Add coffee stain background images

> 1000 pixels wide:

• Add constraints to content wrapper and area to maintain smooth centering

> 1240 pixels wide:

• Show the outer right sidebar (javascript used to load content asynchronously)

Minimizing the pages that were available at the smaller resolutions not only kept the content more focused, but also meant that some of the more complex pages (like the resume) would only be available at resolutions that would support them.

Am I Happy With It?

I started the redesign with the Html5 boilerplate to give me a consistent start place and minimize how much time I had to deal with browser specific layout tweaks. I did tweak the media query resolutions quite a bit as I built out the pages, but part of this was my lack of designer skills and not having a clear enough picture of what I wanted the site to look like.

Currently a mobile device without javascript will load about 83KB of content (obviously this changes based on what is on the front-page of the site). With Javascript this goes up to 160KB for mobile and 800x600 resolutions and 200KB for the largest screen size. I think the smaller resolutions could be reduced further by restricting the inner sidebar content and small icon loading, and the whole site could do with some minification and gzip.

Overall I am very happy with it. The size is usable at every resolution I try and this method doesn't rely on the client-side user agent. Additional functionality would be easy to add, as I could use feature detection to add functionality only if the end user's browser supported it, regardless of the user agent string. I'm very happy with the result.

But we left JavaScript out of the equation.

T4'ing the JavaScript

As a reminder, I am looking for a clean way to store shared JavaScript and CSS in a single place so I share it amongst several web projects and also make changes to the files on the fly and see them in the browser without a costly solution rebuild.

On the JavaScript side of things I decided to write my own little T4 template. The goal was to be able to pick up all of the *.js files in a central location, merge them, and save them out as a common file that I could then include in my local projects.

My solution layout is similar to the one in the prior post:

I prefix my common javascript files with a 2-digit number so I can include them in a planned order every time.

CommonJS.tt

Place this file in our project, update the _targetDirectory variable and we have a quick way to pull common javascript down to our projects.

The output file is a merged version of all of the *.js files found in the common folder. I also output comments around each file block to make it easy to track back to the original file, if needed.

The Price of Hack and Slash Code

I put this script together very quickly and, as such, it is missing some features I think would be nice additions. The ability to execute a minification run at the end would be nice, as would the MarkDirty feature that was in the T4CSS.tt code.

As with the previous post, the sample project is available, so you can look at (or download) a working example if you would like.

And that is that. Shortest Eli post ever? Maybe

The Shared Project

Yesterday the best solution I was also the best one I had thought of on my own, which was to create a shared project and use pre- or post-build commands to copy the common files to the relevant web projects. Unfortunately this doesn't solve the "let me edit a file without rebuilding" unless I then edit the copied file, test, and remember to paste the changes back into the source without first building and wiping out my temporary changes.

Yuck.

This wasn't going to make life that much easier.

Start with just the CSS?

This morning, while looking into the potential of using LESS or SASS to reduce the repetitiveness of the files, I realized I had the potential for a much better solution. If I had a way to compile a LESS or SASS file on the fly into a CSS file, then I could still put my common CSS in a central location and just use an import statement in a template in each project to pull those common values in.

I initially looked at using SASS with the Mindscape Web Workbench plugin. This seemed like a good solution, but something I read recently about design-time T4 templates led me to wonder if someone had created a T4 template that would transform LESS or SASS syntax into a nice clean CSS file.

What did we do before search engines...

Implement T4CSS Template

Phil Haack (blog|twitter) posted a blog in 2009 on exactly this topic. He created a T4 template for Visual Studio 2008 that would use the dotless C# assembly to convert LESS files to static CSS files and provided to the .Less site.

Now we're cooking.

First we need to download the t4css package from github: https://github.com/dotless/dotless/downloads

There are two files we are concerned with, the dotless.Core DLL and the T4CSS.tt template file. The template file is placed in our CSS folder in our site.

Next I created a sample file to play with, which I called test.less.css (fancy, I know). I also modified the settings section of the T4CSS.tt file, setting _runOnBuild and _useCssExtension to "true". This will cause the template to run on each build, as well as when I trigger it, and it will look for files ending in ".less.css" instead of just ".less". This gives us some CSS intellisense with minimal hassle, though Mindscape's Web Workbench apparently handles this out of the box and there is an extension to make VS treat the less extension as a CSS format.

If we keep the T4CSS file open, it will mark itself as unsaved each time it runs, so using Ctrl+Shift+S will save it and regenerate the output CSS. At least that's the theory. Unfortunately in my case, it seems that the template file was being saved prior to the css file, so I've taken to pressing Ctrl+S and then Ctrl+Shift+S after making a quick change in my CSS (which is still way better than a Rebuild All would be).

Note: There is also the "Transform All Templates" button on the top of the solution explorer if I don't feel like double-saving. I could also add a shortcut in the keyboard commands list (Tools -> Options -> Environment -> Keyboard) for "TextTransformation.TransformAllTemplates

Working Across Projects

This solution hasn't quite given me the "save the file and refresh the page" ease of use of a static CSS file. This means if you are editing a less file that more than one template references, and you don't have all the templates open, you could get out of sync. To help keep things clean in source control, this means you should run a complete build (to let all the transforms run) or use.

To make this work for multiple projects we can add a folder at the solution level with our less files and use the @import statement to pull them in. Except now we can't do the .less.css trick anymore because less doesn't process @import's ending in CSS, assuming they are intended to be regular css imports. At this point, it's probably time to stop fighting it, apply the "Less is CSS" extension I mentioned above, and change back to using .less instead of .less.css. Fun times.

So what we end up with is a folder structure that looks like:

And inside the project-specific .less files we have an import at the top, like so:

And there we have it, shared CSS. I posted a working sample project on BitBucket if you want to browse it in detail.

I Specifically Heard You Say JavaScript

I intend to solve the common javascript issue the same way, except in this case I will write my own T4 templates to directly copy the files from the common area that are needed in each project. This will provide me with an easy way to manage common scripts in a central location, the ability to edit and refresh my page to test changes without rebuilds, and can easily be extended to include minified versions of the files.

Today we are going to get into the nuts and bolts of coding automated tests against the WebDriver library. Before we get into that, however, let's discuss when it is appropriate to make this transition.

Context and When to Transition

Most projects that are using browser automation are large and require a fairly complex set of tests. The solutions they are using are at least at the level we will be working at today, if not further down the road to automated acceptance testing. A higher level of complexity across a much larger project is just not manageable with Selenium IDE, so many people are used to bypassing it immediately and going straight to a code solution.

Context is king. For small teams or sites, there is value in being able to put together some quick tests that can be run regularly without making an investment in creating a custom framework. It can also be a useful tool when you have a legacy site and just want to make sure it hasn't fallen over.

Not everyone has worked in the context of these larger projects or has worked extensively with Selenium. If you are getting started for the first time or currently using Selenium IDE, here are some signs to consider moving to a custom solution:

• You often update a number of tests simultaneously to change element names
• Sacrificing your computer while the tests run is becoming a nuisance
• You want to share the tests with team members, others in your company, or your client
• Maintaining the test suite list in the IDE tasks longer than creating tests
• You are starting to build tests for every feature you add to the software
• You want to tie the tests into the automated build system for your software

In these cases, you have likely scaled past the point where Selenium IDE is enabling you, into a range where it's costs outweigh it's gains.

The Next Step for Web Automation

The next step in automating web interface tests is to use the Selenium WebDriver library to code the tests. Writing our own framework has some inherent advantages and disadvantages.

Pros: Free, Reduced Duplication, Easy to share, Relatively easy to automate
Cons: Increased cost, Increased risk due to code errors, Increased complexity
Neutral: Level of fragility depends on level of developer

There are Selenium WebDriver libraries for Java, Python, Ruby, and .Net. By using an existing Unit testing framework we don't have to write our own Test Runner and it is likely to have documentation and/or plugins for integrating into most of the popular build engines.

For the purpose of this post, we are again going to create tests against my contact page, but we'll be increasing the number of tests. We will be using the .Net driver, C#, and the MS Test framework.

Note: I would advise this unit test project be separate from the overall solution for your application. Keeping it separate means you can version it separately, build and run it separately, and easily run the real unit tests in your product solution without accidentally running the interface ones as well.

Note 2: I had intended to do this in VB.Net originally, but the downside of switching easily between languages in the same IDE is that sometimes you find yourself writing in the wrong one without even realizing it.

Getting Started

After creating our .Net solution to house the test project, we need to add a reference to the Selenium WebDriver library. This can be downloaded from the Web Driver Download page or added via NuGet:

Note: If you don't have NuGet installed, I highly recommend you go check it out at http://nuget.org/ or read more about it in this recent MSDN article. NuGet is a package manager that allows us to quickly download, install, and update 3rd party packages in Visual Studio. It not only makes it easier to keep 3rd party libraries up to date, but also makes a number of packages more accessible, since they generally install the appropriate settings and references to easily get us started.

Once we have all of that set up, we can create a single class file with a quick test function to verify we're ready to go:

This is all it takes to get our first test. Create the solution, add the reference, create the test class and method. Since it's MS Test, Ctrl+R, A will run all of our tests in the integrated test runner.

Selenium WebDriver is written in a somewhat fluent syntax, so for the rest of the post we will combine the URL and navigation into a single statement: driver.Navigate().GoToUrl("http://tiernok.com");

The First Test Cases

Last time we started off by testing navigation to the home page and the presence of two books, then we tested submitting a form would correctly fail validation when it was missing a required field. Today we're going to extend that form validation check, a more complex example in Selenium IDE that will be handled fairly easily in our new framework.

The Email Form

These are the situations we want to test for the email form:

When I submit the form without an email address, it displays an error.
When I submit the form without a name, it displays an error.
When I submit the form without a message, it displays an error.
When I submit the form with all of the fields filled in, it displays a success message.

The steps for these tests are going to be similar to the second test we created in Selenium IDE last week.

Exporting a Selenium IDE Test Case

Selenium IDE has a feature that allows us to export tests, so when we are getting started we can look at that export to get a feel for how the code version will function. To export a test, open Selenium IDE, go to File, Export Text Case As, and choose C# (WebDriver). A C# file will be generated with the test case converted to an NUnit Test. The file includes some test setup and teardown methods, as well as the following test method:

Initially this may look more complicated then the Selenium IDE command steps, but really the only difference is that we are explicitly finding the elements we want to act on before acting, which was was more implicit in Selenium IDE.

Converting this to an MS Test is not difficult, but we will want to wrap the tests in a using statement so that driver gets properly disposed (MS Test doesn't run cleanup properly when an exception occurs).

The only real changes have been the addition of the using statement and changing the decorated attribute from NUnit's Test to MS Test's TestMethod.

The Rest of the Test Cases

Based on this one test, we can easily create tests to satisfy the other conditions:

Theoretically we're done, if we had a few more cases we could keep copying and pasting our way to the finish line. If you recall, however, one of the goals of moving from Selenium IDE method to a custom solution was to reduce the amount of duplication and the fragility that duplication causes. So far all we have done is transfer that fragility from a series of test cases in the IDE to a series of unit tests in C#.

Reducing Test Fragility

When we start writing more than basic smoke tests, we are going to be accessing items repetitively and duplicating ourselves more often. Switching to code has allowed us to create additional tests very quickly, but we haven't really solved the duplication issue yet.

There's two approaches we can take at this point, abstracting the duplication on our own or using the Page Factory from the Support library to implement the Page Object pattern.

The idea of the Page Object pattern is to represent each page in our target application as a class in our test framework. This allows us to reflect functionality and changes in the real page with functionality or changes in our class. Rather than locating and interacting with individual controls in a browser, our tests than interact with these Page Object classes as representations of what the browser should be seeing.

Given we are just getting started with the code approach, lets use the Page Object approach for the Contact page and use the PageFactory that is provided in the Support library to help with the wiring.

Creating the Contact PageObject

Before we start making code changes, we need to get the Support library. As before, we can either download it from the Selenium website or install it via NuGet:

Next we are going to start modeling our page. Since there is a common layout throughout the site, I'll first create a base page object to represent the common elements (like navigation menu items) we will be interacting with:

Then we can extend this class to define the elements that are specific to the Contact form:

The PageFactory object is responsible for wiring our page objects to the actual page displayed in the browser. It attempts to match each IWebElement in the class to an element in the web page. By default, if you do not decorate the field with the FindsBy decorator then it will search for an element who's ID matches the variable name. I prefer to explicitly specify the find criteria, though, as this lets me name my variables consistently and limits the impact of an HTML change to a single decorator instead of causing a property name change.

The new code:

navigates to the site
creates an instance of the base page
clicks the navigation link for the Contact Page
assumes it is on the contact page and creates an instance of that object
Sends an email with two of the three values filled in
Asserts that the error message is displayed

However, this code still has problems.

Refining and Correcting the First Test

The current code, in my opinion, doesn't fail soon enough if it is on the wrong page. In addition, this first test we've converted is not very readable and I can already tell there is going to be a lot of duplication in later tests. Let's do some refactoring.

Rather than repetitively initializing page objects in each test and and adding title verification to each test, lets move that behavior to the PageBase so we can easily do it for every page we load.

Now we have a single generic call that can create a Page (provided it inherits from PageBase and has a constructor) and execute an assertion on it's title. Lets update the NavigateContactLink method to return an initialized ContactPage instance, since this will be a consistent next step each time we navigate to a new page. This reduces the amount of code in the test and adds an automatic check to ensure we have reached the page we were expecting.

Our refactored test now looks like this:

There is still some additional refactoring we could do, but this is far more readable, has reduced the level of duplication, and added title checks.

Converting the Remaining Tests

Converting the remining tests is a straightforward exercise.

There is additional refactoring we could do at this stage. The hardcoded page titles and repeated driver.Navigate() calls could be cleaned up to further reduce duplication and make the tests more readable. As we add more pages and more tests, we are going to find other common functionality to refactor and other necessary functionality to add. The framework I end up building through aggressive refactoring of these tests may not look like the one that you end up with, but we will be reaching in the same direction.

Review

We have created the beginning of a more extensive test framework that enables us to create more complex tests with less duplication and effort. Refactoring common elements improved maintainability and our ability to react to changes, while using the PageObject pattern has started to separate the subject of our tests from the mechanics of how we interact with the browser.

As before, though, there are some points to return to.

Complexity, Investment, and Code Errors

Getting started with some Selenium IDE tests was pretty easy. A customer solution, by comparison, scales farther but requires more up front investment and introduces the potential for errors inside the framework that could adversely affect the test results. Despite using an existing Test Runner and the PageFactory object for wiring, I still managed to make errors along the way. In one case, I actually lost time chasing down something that I thought was a timing issue (which you will run into at some point) that was actually a simple error in my code.

Experience helps a lot in this area, as does following good code craftsmanship standards, refactoring aggressively, using consistent naming, and trying to keep the bigger picture of the framework in mind. Along the way I made variable type selections to specifically set myself up for later additions I want (choosing RemoteWebDriver over IWebDriver in several cases, for instance) and despite needing only one NavigateClick function for this sample, I created a pattern I would intend to follow for the rest of the navigation menu. Experience will help tell us these things are available, but first we have to make the mistakes and experiments along the way to gain that experience.

Moving Forward

From automating basic smoke tests and HTML element interactions we have moved into the realm of interacting with web pages and actions on those web pages. We can abstract a step further, though, and start focusing on validating what the end user has asked for. The next level is a framework that abstracts the web page away, leaving us to interact with higher level functions and processes, validating whether the application fulfills the users acceptance criteria.

Finishing Up

The Selenium WebDriver library offers some great capabilities. Using a handy Unit Testing framework and Test Runner can help give us a solution that is halfway between automated acceptance testing and Selenium IDE in a fairly short period of time. There are still a lot of areas we haven't discussed, such as integrating with a build server or tying into multiple browser drivers, but this post has already run a bit longer than the prior one. If you are interested, the code for this post is in a mercurial repository on bitbucket and as always we can continue discussing any of the points in the post in the comments here or in the forum area.

Enter browser automation tools, such as Selenium. With browser automation tools we can invest some extra time up front to define those manual tests in code, then continue to run those tests long past the time we would have stopped doing it manually.

Note: This post is a walk-through for creating some automated browser test cases. To get the most from it you will probably want to download the tool below and launch it from a second browser so you can follow along. It assumes you have Firefox installed and are comfortable with HTML and css selectors.

The Smoke Test

There are levels to automated testing, starting with "none" and ending with some fairly complex industry packages and/or in-house frameworks. Today we're going to look at the cheapest option, recording and rerunning a set of tests using Selenium IDE, a Firefox browser plugin. At this level we can replace many of our manual smoke tests with an automated set for a low initial investment.

Selenium IDE is a browser plugin that can record and playback actions we make in the browser. Using Selenium we can record a set of paths through our website, add some checks, and be reasonably confidant that the site is still working.

Pros: Free, Low up front time cost
Cons: Tests are fragile*, Potential for lots of duplication*, tests run on local browser
Neutral: There's a learning curve but good documentation and quick feedback*

* I'll come back to these three points

For the purposes of the post, we will use a couple pages from my personal website. We will create two tests to verify the main page loads properly and that the contact form submits and validates properly. In the even that I make a change to a shared file, these tests will ensure the pages continue to pass some basic tests.

Getting Started

First we need to download the plugin (assuming you have Firefox installed): Download Selenium IDE.

After downloading the plugin and restarting, we should have a "Selenium IDE" option in the Tools menu (Windows users can press the 'Alt' key to see the top menu).

Selenium IDE in the Firefox Menu

Pressing that Selenium IDE button will give us both a popup interface and a set of release notes that unfortunately are probably less than useful to a first time user.

Selenium IDE

The main areas of the interface are:

• A test case list on the left which displays the list of "Test Cases" in the current "Test Suite"
• A command window in the main viewing area, which will display the individual commands we execute as part of selected test case
• A series of tabs at the bottom, of which we will only be interacting with the Log and Reference initially

So now that we have an interface, lets jump into creating the first test case to give us something to explore.

Note: The FireBug Firefox extension is an invaluable tool when working with Selenium, I highly recommend you download FireBug if you don't already have it.

The First Test Case

Before we start recording our first test case, it's a good idea to create a saved Test Suite file. Pay careful attention to the title bar for the file dialog, as it will first ask you to save the Untitled test and then ask to save the Untitled Test Suite. Out of personal preference, I use a ".testsuite" and ".test" extension for my selenium IDE files.

Test Suite

A group of test cases, including their name and filename

Test Case

A series of commands that reports a single Pass/Fail result when they are run

We are now ready to start recording our first test. This test will click the "home" link in my website, verify we are on the right page, and verify two books are shown from my reading list.

Creating a Basic Recording

With our browser open, click the red circular icon on the right side of the Selenium IDE toolbar . This tells Selenium IDE to start recording our browser interactions. Returning to the browser window, enter "http://tiernok.com" in the address bar to navigate to the site. Click the "home" link in the navigation will load the index page. Once this is done, we can return to the IDE and stop the recording by pressing the record button again.

At this point we see a few things in the interface.

Selenium IDE - Getting Started

The Base URL field above the toolbar has populated with the URL of the site we are testing, the "Untitled" test case has a star next to it to indicate unsaved changes, and the command list in the right window has been populated with two commands. Let's save these changes (Ctrl + S) and test them. Navigate the browser to a different site, return to the Selenium IDE window, and press the "Play Current Test Case" button (the play symbol with a single horizontal line in focus). As expected, the browser opens the root URL (step 1), then presses the "Home" link. The results are displayed under the test case list as 1 Run and 0 Failures and we see the details of the commands echoed in the Log tab at the bottom.

Now that we have the mechanics, lets add verifications. We are going to make some assertions about what should be displayed in the page and Selenium IDE will test them for us. The first thing we want to do is make sure we ended up on the correct page, which we can do by asserting the title of the page.

Adding a simple Assertion

To add an assertion command in the command list, select the empty row below the "clickAndWait" command.

Selenium IDE - Adding a Command

Under the command list, we have three inputs for the new command: "Command", "Target", and "Value". Theoretically these are used to define what command Selenium should execute, the target it is acting on, and a value for the command. These are not always 100% accurate, as we are about to see.

In this case we want the command "assertTitle" to indicate our expectation to Selenium that the page title will be a specific value. As we start typing it, the command dropdown will filter the list of available commands. Once the command is entered, Selenium IDE populates the reference tab with additional information about that command. Since "assertTitle" doesn't have a target, we can simply enter the value of the page title into the "value" field.

Let's try an incorrect value first, just to see what happens when a test fails. Enter "ice cream" or something else nonsensical as the value and run the Test Case again.

The result is different this time. Under the Test Case list we still have 1 run, but now we have 1 failure and a red bar. In the command list to the right, the "assertTitle" line has a red background (unless it currently has focus). In the log at the bottom we have some red text indicating the command that failed.

Selenium IDE - Results

We have actually learned one more thing. If we look closely at the error we will see that it tried to match the page title against an empty string and failed. The "assertTitle" command actually reads it's argument from the "target" input, not the "value" one. A better way to think of these inputs is as "Argument 1" and "Argument 2" rather than as "Target" and "Value". If we put the value "Eli Weinstock-Herman | Tarwn" in the "target" input and run the tests again, it should Pass.

Selenium IDE - Results

Which it does. Now we need to move on to the slightly more complex case of verifying the presence of elements that change on every page load.

Asserting Something Is Present

There are a couple different commands we could use to create this test. For the purposes of the post, we will use the "assertElementPresent" command to verify the first and second books are available. Using Firebug (F12, Inspect button, hover over a book), we can see there is a "book" CSS class that wraps around the image and title text of each book.

Add a new command to the Test Case, this time entering "assertElementPresent" in the "Command" input with a target of "css=.book". There are several locators we can use here, for instance xpath= would allow us to use an xpath locator. To verify the target string, press the "Find" button tot he right of the input. If Selenium is able to find a match, the element will flash briefly in the browser window. Additionally, double clicking the command in the command list will test just that line and report the result.

To test that there are two books, we are going to be sneaky and use the CSS selector "css=.book + .book". Since this CSS path will only locate an element if it finds two book elements in a row, it is an easy way to verify that both are present. We can update the command with this new locator target and run the Test Case to see it passes successfully.

Selenium IDE - Test Case Commands

The last thing we need to do is rename the Test Case to something useful. Right-Click the Test Case in the Test Case list on the left and edit the test name. I named my test "HomeLinkDisplaysHomePageWithBooks", which may seem a bit clumsy but tells me exactly what I'm tetsing without loking at the details.

Note: Attempting to test too many concepts in a single test makes the test more fragile (ie, increases the frequency we will need to update it as we make site changes) and requires more digging to determine what failed when the test doesn't Pass. A Descriptive name is not only useful but helps keep me from combining too many tests.

Note #2: Another option for this test would have been the "assertXpathCount" command that allows us to enter an xpath argument and verify the return count matches a specific number.

The Second Test Case - Adding some Interaction

Now that we can create a test case that makes some basic assertions about the page, it's time to move on to a test that requires some interaction. In this case we are going to test that the contact form properly submits and returns an error when we enter less than the required number of inputs.

Recording the Test

To start, lets create a new test case by selecting "New Test Case" from the File menu in Selenium IDE. Like we did with the original test, lets save this one before we make any changes. I am going to call my test "ContactPageReturnsErrorWhenEmailFieldEmpty.test".

Note: Something to consider when naming tests is how you want to organize them. Besides being descriptive, I also try to use a consistent pattern to make them easily sortable/searchable in the file system.

Let's start another recording and open "http://tiernok.com" again. Click the "Contact" link in the top navigation, enter text in the Name and Message inputs in the form, then press the submit button. That's the whole workflow, so lets stop the recording and see what we have.

Selenium IDE - Test Recording

This test has some new commands in it, but they are pretty self explanatory. We opened the root site, clicked on the "Contact" link and waited for the page to load, typed in two input boxes, and clicked the submit button, again waiting for the next page to load. To finish up the test, lets add an assertion for the error message.

Asserting the Error Message

Like the earlier Test Case, there are a few different ways we can write this assertion. In this case the two obvious methods are using either "assertTextPresent", which tests that the text shows up somewhere on the page, "assertElementPresent", which could look for an element with the ".err" CSS class, or "assertText", which combines the two commands above to test that a specific element has specific text.

Selenium IDE - Error Assertion

I've used the last option in my Test Case (as well as Firebug again to locate the element in the browser). If I save the Test Case and run it, I should see the browser run through the steps and Pass, just like our earlier test.

Note: You may have noticed the Fast->Slow slider above the Test Case list on the left. This slider controls how fast or slow the individual commands are run when processing the tests. It can be helpful to run individual tests slowly, but the fast setting is useful when you want to run multiple tests or the whole set.

Review

Through the course of the post we have created two basic tests. Neither took very long to create and it wouldn't take long to expand this suite to cover the entire site. Selenium IDE makes it easy to create basic test cases and tie them together into a suite. The tools, augmented with Firebug, make it fairly easy to build the series of commands for each Test Case and there is a fairly detailed command reference available.

However there were some points I mentioned above that I need to return to.

Test Fragility and Duplication

Tests in Selenium IDE tend to be somewhat fragile. In general, automated interface tests have a certain level of fragility because it's easy to break them simply by moving a few elements around or renaming some controls. The Selenium IDE is on the extreme side of this curve because these values are used at the individual command level rather than having a central list of search or match strings.

We can reduce the effects of this fragility by keeping tests shorter, as shorter tests are easier to correct or update. Selenium IDE has the ability to define suite-level variables, so in some cases I created variables for common strings and put those declarations in a first "test case".

Other Limitations

In addition to the fragility above, there are other limitations. Using a Test Suite to test two separate base URLs (for instance a Dev and a QA version or local and production) is difficult and requires some trickery. Scaling the tests can also be tricky, especially if you are used to the ability to run categories of unit tests or select subsets to run on the fly. There is also the issue of leaving your PC alone long enough to run the tests, since the browser will steal focus as it's running tests.

Note: There is also another oddity. When you have Selenium IDE open, links that open in new tabs or windows will be opened in a new window without the ability to scroll. This has gotten me more than once.

And That's a Wrap

Selenium IDE offers an excellent first step for verifying everything is working from the interface level. It also provides a great introduction into the mindset of using a web automation framework for testing and has a lot of power for a very cheap price. While there are some limits to how far this approach will get you, the gains are fairly cheap and can be a real time saver. In a later post I will talk about the next step, interfacing directly with Selenium WebDriver from code to test a site.

Next Post: Automated Web Testing with Selenium WebDriver

I typed "javascript unit testing" into Google and started reading.

jsTestDriver

jsTestDriver was listed on a wide number of sites as one of the top JavaScript unit testing tools and fit an initial requirement I set myself of running outside of a browser. jsTestDriver runs as a client-server pair, the client sending tests to the server, which then runs them on a captured browser. The advantage of this method is it can easily be integrated with a code editor or as part of an automated build.

The jsTestDriver site includes plugins for Eclipse, Maven, and IntelliJ. I also found an article on using it with Visual Studio and it was fairly easy setting it up as a user tool in EditPlus.

Screenshot of EditPlus Settings

Though I'm not using the feature, jsTestDriver provides a flag to specify an output file for the results, enabling us to use it as part of a continuous build.

The Setup

Setting up jsTestDriver on my system was fairly straightforward.

1. Download Java - Visit java.com and download the appropriate installer, run the installer, remember to go into the control panel and fiddle with Java's update settings
2. Download the jar file - Visit the project on Google and download a copy of the jar file (I used the self-contained version)
3. Create folders - Create a top level folder and two sub folders (for instance, src and src-test). Put the jar in the top level folder
4. Create a conf file - I used the one in the Getting Started Guide as a starting point

At this point we should be able to fire up the server for the first time and verify everything is ready to go. I created a .cmd file on my system for the server so I could easily start it:

What this does is starts the jsTestDriver jar on port 4224 and also automatically starts up an instance of chrome that will be captured by the server to run tests. I was initially using Firefox but jsTestDriver can't intercept the console log the way it can with Chrome, so I wasn't getting very good output for failed or errored tests.

Next I created a .cmd file to run all the tests in my folders:

This tells jsTestDriver to run all available tests (based on the settings in the conf) using a jsTestDriver server on port 4224. I ended up not using this cmd file very frequently, as it was much handier to be able to run them from a key command inside my editor.

Writing Tests

Once we have gotten this far, we can start writing some simple tests.

In each directory (src and src-test), create a file named "mystuff.js".

src/mystuff.js

src-test/mystuff.js

JavaScript provides a number of different methods to define objects with functions, in the source class I used the prototype method and in the tests file I used an object literal. For jsTestDriver, the important part is that the tests in the object we pass to TestCase begin with the word test, and the object literal method seemed like a friendlier layout for a test file.

Running Tests

Once we have the two files in place, start the server by issuing the following command (or creating the cmd file like me):

You will need to update the browser and java paths to reflect your own.

Once the browser has started and it has been captured by the server for testing, it will look like this:

Chrome captured by jsTestDriver Server

Now we can run our tests by issuing the following command:

Again, you will need to change the java path to reflect your own (or remove it if you have added it to your PATH variable).

The results should look something like this:

....F
Total 5 tests (Passed: 4; Fails: 1; Errors: 0) (0.00 ms)
  Chrome 13.0.782.220 Windows: Run 5 tests (Passed: 4; Fails: 1; Errors 0) (0.00 ms)
    Object Literal Test Case.test Fails miserably failed (0.00 ms): AssertError: miserably
      AssertError: miserably
          at Object.test Fails miserably (http://localhost:4224/test/src-test/mystuff.js:22:3)

Tests failed: Tests failed. See log for details.

The top reflects the tests that have run at a glance with .s for passing tests, Fs for failed, and E for errored. Afterwards we get a summary of the total counts and then a section for the one browser we ran with. jsTestDriver allows you to capture multiple browsers, so we could configure this to run our tests across chrome, firefox, and IE simultaneously.

jsTestDriver also supports "setup" and "teardown" functions to run before and after tests.

Qunit

Qunit is a browser-based solution that was built to unit test the jQuery framework. Qunit has fewer requirements to run, but because it runs directly in a browser it means we have to switch windows and refresh in order to get an updated test run.

The Setup

Because Qunit will run in our browser, there are relatively few requirements and unlike jsTestDriver, none of them are installations.

1. We already made our folders, so nothing to do here
2. Download the necessary include files to the top level: qunit.js and qunit.css (I renamed mine without the -git)
3. Create an empty html file in the top level

The empty file will be our test runner. Update the file to look like this:

As you can see, we are referencing a CDNed version of jQuery, the local qunit files we downloaded, our source file, and a test js file we haven't created yet. The remainder of the HTML will be used by Qunit to display the results.

Writing Tests

Writing test in Qunit is pretty straightforward. Since we already have the src/mystuff.js file from above, we can jump right in and create a qunit version of our test cases.

src-test/mystuff_qunit.js

Qunit's equals method has it's actual and expected arguments reversed from jsTestDriver, instead expecting them in this order: Qunit.equals(actual, expected). I didn't originally notice this and had to update both the jsTestDriver test mapping script and the sample above (here and in bitbucket).

Running Tests

Opening the testrunner html file, we should now see it display a block for each test that we have defined above.

QUnit Results

Failed tests automatically display details. Any test can be toggled open/closed by clicking it's name, and a handy "rerun" button lets us re-run a single test.

Combining Them

By writing a small amount of glue script, I was able to re-use my jsTestDriver tests in Qunit. Since I am currently only using a small subset of assertions and using the object literal method, the glue script is limited to only exactly what I needed.

Add this file to the top level folder:
jsTestDriverInQunit.js

And update the testrunner HTML file we created to look like this:

And now whether we run the jsTestDriver client/server or open the Qunit file, we will be running the same exact set of tests.

There is also a project that translates Qunit tests into tests that can be run with jsTestDriver.

All of the source code for this post (as well as the content of a couple programming katas) can be found in my javascript repository on BitBucket. The folder structure is slightly different to cut down on duplication of resources.

Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: The connection name 'LocalSqlServer' was not found in the applications configuration or the connection string is empty.

Today I managed to solve it based on an archived forum post I found through google.

The solution is to add the following section to your web.config:

Basically what is happening is that my web host has a machine.config with a SQL Connection string called "LocalSqlServer" (it's created by default by the .Net framework). For some reason when we use anything Membership related, it attempts to access the configured connection string for Membership, even though WebSecurity is provided it's own connection string on initialization.

So the solution is to remove the settings that has been applied to our site from the host's machine.config and apply a new one. From what I can tell, it doesn't seem to matter if the new connection string is accurate, only that it exists.

Yep, this means I don't actually have a SQLCE database named, MyJunk. I can tell you're disappointed. Also I don't know if ./ would work in this path, so please don't use this as a how-to guide on how to create a working SQLCE connection string.

The argument over table vs non-table layouts has been going on for years. I remember seeing online conversations as far back as ten years ago on the topic, and given my notoriously bad memory that should be taken as a minimum. Along the way we have dealt with partial CSS implementations, inconsistent rendering behavior, slow implementation of standards, competing proprietary implementations...it's been a long road.

Table layouts are still in use and in some places they are still the default. They are easy to implement and the browser and standards wars of the late 90's and early 00's have left behind a lot of people who remember how impossible it sometimes felt to make a non-tabular layout. However, while there are still browser inconsistencies and delays in standards adoptions, sometimes I wonder if we have forgotten just how long it has been since we started down this non-tabular path.

Table-free Layout is "New"

Tables have existed as part of web standards since the HTML 3.2 standard (January 1997). The standard referenced an earlier RFC and was intended to be compliant with the table tags Netscape had already added to their browser, but this was their official addition to the HTML standard.

The standard pointed out that tables could be used for tabular data or layout purposes, but cautioned that using them for layout would impact accessibility.

In HTML 4 (April 1998), this warning was strengthened to "Tables should not be used purely as a means to layout document content", and we were pointed to the addition of CSS1 to help accommodate this. It was noted, however, that using deprecated features was expected to continue for a little while in order to support older browsers (browser listed above).

In HTML 4.01 (Dec 1999), this warning was strengthened to the following directive: "Tables should not be used purely as a means to layout document content".

Tables have existed as part of the HTML standard since 1997, we've been warned not to use them for layout, and CSS1 was added to the standard in 1998 to provide layout flexibility without having to resort to tables. While implementation of CSS1 was slow, the inconsistencies we saw between IE4, IE5, and NS 5.4 are a long time back.

If you are interested in the CSS side of the history:

CSS1 Recommendation

was published December, 1996

CSS2 Recommendation

was published May, 1998

CSS2.1 Recommendation

began in 2002 and was published in 2011

CSS3 at Wikipedia

began in 1999 and is a collection of modular standards being published independantly

Out of curiosity I pulled up my personal website from 2002 and checked the source. It was cross-browser compatible and the layout was table-free.

Fast-forward:

Fast-forward:

CSS Takes Longer

There was a point in time when you could spend days trying to get the screen to layout properly. Oddly enough, with the slower internet connections available at the time, it was probably worth it to remove all the extra markup table layouts tend to incorporate.

The amount of time it takes to produce a layout in CSS versus tables has gotten fairly close. With the consistency shown by today's browsers, the major gap in time is generally learning how to do it. That's not to say that all is perfect in the world of browserdom, but it's rare (unknown?) to be forced to use the table option given the number of available examples, prebuilt frameworks, and tweaks available from javascript packages.

Building a house is hard. Can the house builder cut corners to get your house up faster? Sure. But at the end of the day, if the builder is professional they won't cut corners because those cut corners reduce the value of the house, reduce the satisfaction of the buyer, and increase the ongoing maintenance costs.

The Exceptions

There were exceptions and they got fewer every year. As IE 5.5 and NS 4.6 faded from view, this grew to very few exceptions. Add things like jQuery to the mix and I would be hard-pressed to find an example that required the negative baggage table-layout brings with it. Initially we created fixed width layouts, then along came fluid layouts, then elastic layouts. The latest entry in the game is responsive layouts, where we not only change the overall size of the page to accommodate browser sizes, but also element sizes and flow.

Resorting to table layout immediately means you aren't treating it as an exception. It's more likely you need to sit down with your manager or business and help them understand the ongoing costs involved with table layouts, some of the benefits available with newer techniques (ie, 2000 forward), and why it's important to start making the switch. Luckily there are resources out there to help.

There's "No Time"

I understand deadlines, the pressure from the business to deliver, and the fact that many companies simply don't bother to grow their people. As we mentioned before, it can be difficult to convince our managers and business to understand why we need to go the, initially at least, slower route of non-tabular layout.

But you need to go get started. Yesterday.

If your company is hesitant to let you spend the time, point out the costs involved with supporting new browsers as they come out, the advantages of good searchability, the wave of mobile devices that are flooding the market...clean markup can help all of these and there's any number of sites out there that will provide longer, better articulated lists of costs and benefits (we've had a lot of time to think about it).

And don't forget to point out that since table layouts are contrary to the standard, what you are actually providing to your customer is a defective product.

Moving Forward

When we follow standards, the browser developers can spend more time on new and interesting advancements. When we violate standards, we force them to spend time making sense out of the random, invalid junk we've sent to the browser.

Poorly structured, non-standard HTML (like table layouts) takes more bandwidth, takes longer for browsers to render, is more fragile, is harder for experienced web developers to work with, basically forces a rewrite for mobile devices, wastes the time and efforts of browser developers ... it's bad code.

It might be acceptable for a beginner to use tables for layout, by definition a beginner is just learning the ropes. But part of being a beginner is learning and growing past that stage. With non-tabular layouts being around for 13 years, it's long past the time we, as professionals, start requiring ourselves to know how to use them.

So here's a couple tips, tricks, and the occasional slip in the mud I picked up along the way.

Chrissie started us off with this post, so I'm skipping right past the making of files and digging into the first layer of how things work (and/or how I broke them).

Note: I know in my last post I said the application was WebMatrix and the programming framework was WebPages, but no one calls it WebPages (apparently that name is hard to search for or something), so for the remainder of this post I'll call it WebMatrix. Feel free to call me names later.

Magic Routing

The first problem I had when I deployed my site to a live host was getting the darn pages to work. No matter how I typed the paths, the cshtml pages wouldn't stop reporting a 404. So of course I started digging into the IIS settings. And fixed the meta settings. And fixed the extension. And fixed something else. And then found out I wasn't supposed to fix it and the real problem was the guy sitting behind my keyboard typing instead of reading the manual. Oops.

When we build a razor site (or is it a WebPages site? WebMatrix site? argh...), it takes advantage of additions in the 4.0 Framework to provide routing automatically. Every cshtml file we create automatically becomes part of the route check when a request comes into IIS. This is similar to the ASP.Net MVC routing, but instead requires no up front work, running 100% on pixie dust.

Say I ask for http://MyAwesomeSite.com/blueberries/and/cream. Note that we don't include the .cshtml extension. Behind the scenes, my webserver basically has this conversation with itself:

Do I have a file named /blueberries/and/cream.cshtml?
No.
How about /blueberries/and.cshtml?
Nope.
How about /blueberries.cshtml?
Nope.
Maybe there was a default file at the root level?
Ah, ok.
Are you busy tomorrow night...
Yep.
Oh...er, ok, well here's your file then.

The most specific file match wins, without the need for setting up routing ahead of time. Simply drop an appropriately named file in a folder and point an href at it.

Any trailing portion of the URL is then stored in an array for easy access (which we will see later). What this allows us to do is create very easy, semantic URLs.

Example: my application will show me the list of all activities when I go to http://notmyrealurl.com/Activities but will filter the list for the "razor" tag when I go to http://notmyrealurl.com/Activities/razor.

The exception is files that begin with underscores. Underscored files are not accessible, as they are used to protect our Magic Files in the next section.

Magic Pages

Ok, so this part I'm less enamored of, but there are some good parts. There are two classes of special files in WebMatrix, layout files and lifecycle pages.

Layout Files

Layout files allow us to define a common layout that we want to apply to our website, basically a template or master file. Inside the layout file we can define where we want the main body to be rendered (the file that was requested), as well as additional required or optional sections the original page needs to provide. A minimal layout file would look something like this:

A basic page that includes a header file, an optional section named "SidePane", and body of the original page, and finally an included footer file. In this sample I am keeping my _Header, _Footer, and _MainLayout files in a subfolder called Shared. To use this layout, I could make a sample page like this:

And if I wanted to both show off the presence of any extra URL data you put in the URL as well as the optional sidepane?

Yeah, I just used a blink and a marquee, that's how exciting this part is. You'll notice I also put a value in the PageData dictionary at the top of the page, which was then regurgitated by the layout and used as the title. When files are being rendered or included, they receive a copy of the PageData and can access the values we squirreled away. Handy.

There's also a Page dynamic property in WebBasePage that we can assign stuff to. So far that hasn't blown up in my face.

If I think back to the classic ASP days I can remember a time when we desperately wanted this type of functionality. A clean, straightforward way to define some sitewide layout templates separately from our actual page, and here it is. It's like ASP 4.0.

And I only just now noticed that interesting conjunction in ASP and ASP.Net numbering schemes, hmm.

Lifecycle Pages

Then there are the lifecycle pages. Where layout files give us a handy way to do templating, these provide us some basic global capabilities for the site. There are three main files that we are concerned with:

~/web.config

This holds configurations for the site, like any ASP.Net site

~/_AppStart.cshtml

Contains logic to run the first time any page is requested from the site

~/_PageStart.cshtml

Contains logic to run when a page in the current or child directory is requested

AppStart is handy for setting values or creating objects that will have global application scope. For example, when using the SimpleSecurity helpers, you will want to put an initialization call here to initialize the authentication system.

And if you are me you will comment them out when you find out your webhosts machine.config fubars settings relevant to ASP.Net membership.

PageStart is trickier in a couple ways. First, PageStart is a bit of a misnomer. It does execute at the start of the page, but it can also be convinced to encapsulate the execution of the requested page, running both before and after the main page is rendered.

If you specifically include the RunPage() line, then your page will be run in between the code above and below it. If you don't include this directive then the entire PageStart file will be run before calling the requested page.

The next trick is that _PageStart runs in a nested sequence from the root level to the level of the file that has been requested. Basically the engine traverses each directory from the root to the folder your requested file is in and, if a _PageStart file is present, executes it. It's similar to those nesting dolls (or recursion, oohh).

But the magic is not done yet, and this was one of those pits of mud I fell into.

Even though you can wrap the execution of the page inside a _PageStart, the execution of the page and PageStart finish before the Layout is applied and executed.

Lets try that again (I lost 2 hours of my life to this feature).

Say we have a _PageStart that wraps around the RunPage call, a Main page, and a referenced _LayoutMain file and we request http://myevilpitofmud.com/Main. The execution would look like:

1. Top part of _PageStart
2. Main file
3. Bottom part of _PageStart
4. Layout file

Yeah.

But what else did you do?

There's more. I've spent 17 hours on my sample site so far, which includes implementing a SQL Compact database, implementing and removing WebSecurity authentication, and a score of other things. I've found out the hard way that getting fancy can bite you and that it is actually possible to install a 10 inch tailpipe on the WebMatrix hatchback (which I just realized could refer to two different things I've done, hmmm, tailpipe and a shopping cart handle spoiler then).

Unfortunately because I had issues with the authentication I can't post a live link yet, the next post will have to cover all the fun that has gone into trying to get a certified host for WebMatrix to run correctly (hint, not all 'SpotLight' hosts can run the included, basic example sites).

What Level Am I?

Rather than try and attach years of experience to this scale, I'm going to present a list of major areas and skills, questions, or topics in each area. I've tried to capture whether I feel a skill is required to be an Intermediate or Advanced web developer.

I put this list together based on my own experience, 20-30 web developer interview lists, and some feedback from others.

Beginner: Knows some of the items on the list
Intermediate: Knows most intermediate items and some advanced
Advanced: Knows almost everything on the list

Note: Disqualifiers indicate that you won't progress past [B]eginner or [I]ntermediate levels until you stop doing them and understand why doing them was a bad idea

What's Missing

There are several things that were intentionally left out of this list. Some were hard to quantity in a general manner, others I was unsure how relevant they were. And I'm sure people will be kind enough to add additional oversights and revisions below.

Missing Categories:

• Level of knowledge with server-side languages
• Project management skills
• Documentation and Modeling skills
• Design and Graphics skills
• Application Lifecycle Management - Source Control, Deployment, etc

Extra items that didn't make it in:

• Can implement RSS and ATOM feeds
• Can implement a web farm
• Implemented single-signon (openID, SAML, etc)
• Knows how to implement XML data islands (still relevant?)
• Knows how to create DTDs and/or XSDs
• Can write regular expressions without a reference
• Knows relevant tools for Yahoo (SiteExplorer), Google, Bing for managing site information
• Schema.org - it belongs in the Meta category but I didn't know what level of skill, knowledge, or adoption I should include considering it's newness and several other factors

There is also the fact that we often get caught up maintaining or even adding on to a site that violates many of the skills and standards you see in this list. This doesn't prevent us from writing good, clean, semantic sites the rest of the time and being forced to write poor code does not make on inherently less skilled.

A Brief Digression, or Why an App Dev is Not a Web Dev

At one point web development was seen as less exciting and far less complex than application development. It is still seen as extremely similar to application development, so much so that it is quite normal to hire a good or great application developer and expect them to be a good or great web developer.

Unfortunately it doesn't quite work that way, as web development has grown extremely complex since the first dynamic sites started showing up in the late 90's. Doubly unfortunately, web development is based on a stateless model instead of the stateful one most application developers are used to, uses a fluid layout instead of the grid layout, and sneaks a lot of extra communications and caching into the mix. This is a series of paradigm shifts not unlike the one between procedural, object oriented, and functional programming.