Obviously not.

This second part of this post gets in depth as to what's going on with the MicrosoftMvcValidation script, but to save you some time, I'll post the solution first.

To manually validate your form with MicrosoftMvcValidation.js:

In MicrosoftMvcValidation.js, change line 20 from:

return Sys.Mvc._ValidationUtil.$0($2.validate('submit'));})); return $2;

to

return Sys.Mvc._ValidationUtil.$0($2.validate('submit'));})); $0.MvcValidationFormContext = $2; return $2;

Alternately, if you're using the debug version of the script, you can achieve the same effect by adding the following to line 196 (the end of the _parseJsonOptions function):

formElement.MvcValidationFormContext = formContext;

UPDATE: As Morten Christiansen points out in the comments, there is a much cleaner way of accessing the FormContext object, without having to introduce a custom tracking property and modifying the script. Instead of a custom property, we can just use
$('form')[0]['__MVC_FormValidation']. Thanks to Morten for pointing this out!

Now we can use the following jQuery/javascript code to manually validate our form:

var $form = ("#MyForm");                            // Select our form with jQuery
var context = $form[0].MvcValidationFormContext;    // Access the new property we created
var errors;
if ($form[0]['__MVC_FormValidation']) {
    errors = $form[0]['__MVC_FormValidation'].validate("submit");        // Validate the form
}
if (!$form[0]['__MVC_FormValidation'] || errors.length == 0) {
    // No errors, do your stuff
}

I assumed (incorrectly) that there must be a client-side API to MicrosoftMvcValidation.js, the javascript responsible for dynamic client side form validation that ships with the ASP.Net MVC framework. Unfortunately, in all my digging, I could not unearth one -- and it seems like a huge oversight. The amount of effort to expose an isValid property or a validate() function on the client would be pretty minimal!

Why would you need to do this? Doesn't the validation occur automatically? Well, yes it does -- when you submit the form, or click around in it. However, there are lots of cases where you might want to manually trigger the error messages or perform a client-side action based on whether or not the form is valid, without running the submit handler. In my case, I wanted to make sure the form was valid before trying to submit it, as our ajax pipeline puts up the "spinner" graphic when a submit event is triggered, which meant it was flashing briefly and looked dumb.

The most common response I ran across when searching for how to manually validate was -- give up and use the jQuery validate plugin. This would be my preferred solution to be honest, but I ran into at least two blockers with jQuery validate:

1. it doesn't seem to work with modal dialogs generated from jQuery UI,
2. it doesn't seem to work with forms that are loaded into the document via an ajax call.

So that was out. Since I already had most of what I needed working with the Microsoft scripts, I went back to them and started exploring the code to see if I could discover any sort of public API. This is what I came up with.

The key thing that I found was that MicrosoftMvcValidation creates a javascript object called a FormContext, which has a validate(eventName) method. This seemed promising, so I tried following the code to see how I could get at this validate method. Well -- I couldn't. Not without some modifications. Here's how it works.

When you include MicrosoftMvcValidation, the main piece of script that executes is this:

Sys.Mvc.FormContext._Application_Load = function Sys_Mvc_FormContext$_Application_Load() {
    var allFormOptions = window.mvcClientValidationMetadata;
    if (allFormOptions) {
        while (allFormOptions.length > 0) {
            var thisFormOptions = allFormOptions.pop();
            Sys.Mvc.FormContext._parseJsonOptions(thisFormOptions);
        }
    }
}

Adding <% Html.EnableClientValidation(); %> to your views causes a bunch of JSON data to be output to the page, and appended to the window.mvcClientValidationMetatdata javascript object. When the page is ready, the above function runs and calls FormContext._parseJsonOptions() on all the rules and data that were output to that object.

_parseJsonOptions is what creates the FormContext object that we're interested in. In fact, the return value of _parseJsonOptions is the FormContext… but sadly, Application_Load ignores the return value, and it's just thrown to the bitbucket, never to be seen again (at least by us).

Judging from the underscores on the function names, it's pretty clear that these are meant to be internal operations, so we can (perhaps) excuse them for not storing and exposing the FormContext for us. From the framework's point of view, it doesn't need to be stored anywhere, because it still has it -- _parseJsonOptions internally adds new event handlers for the form, and these handler delegates close over the FormContext object. The closures means that internally, the form handlers still have a saved reference to what they need, so the application load function doesn't need to do anything with the return value. The FormContext never surfaces -- so if we want to validate the form ourselves, we need to expose dig for it.

All that my code at the top of the post is doing is modifying the _parseJsonOptions function (minified to be named $12), to start adding a new property to the form element in the DOM, which will store the created FormContext object. I named this property MvcValidationFormContext, but you could call it anything you'd like. You can subsequently access this new property to get the FormContext and call validate("submit") on it, which fires the validation as though we were trying to submit the form, and returns a collection of errors we can check.

As Morten pointed out, the reference is, of course, still there. You can access the closed over FormContext by grabbing the DOM element and digging in it's properties array. The updated code reflects this.

The question on Stack Overflow is titled "How do I route images with ASP.Net MVC", but fundamentally the question is really asking "how can I use ASP.Net MVC to re-route URL's to actual physical files, rather than methods of a controller?"

To be clear, lets address the conceptual differences between routing and url rewriting.  Url rewriting takes the requested URL and modifies it before your code ever sees it.  As far as your application is concerned, the client requested the rewritten URL.  All that URL rewriting does is to change one URL into another URL, based on pattern matching.

Routing is a different and much more powerful beast.  The ASP.Net routing engine maps an URL to a "resource", based on a set of routes.  The first route to match the requested URL wins the prize, and sends the request off to the resource it chooses.  For the ASP.Net MVC framework (which uses System.Web.Routing under the hood), a resource is something that can handle the request object, which is always a piece of code.

So where does that leave physical files?  If a request is always parsed by the routing engine and then handed off to some function somewhere, how can we ever route a request for an image to actually return the physical image?

Well, it takes a tiny bit of legwork, but once we're through it, I'm confident you will see the huge advantages that routing has over simple url-rewriting.  We will show the equivalent of url-rewriting by handling a request for an image using an URL that doesn't map to a physical path, but be able to return the image anyway.

Handling the Request

First off, we need to handle the request that we want to re-route to a physical file.  Out of the box, ASP.Net MVC uses an instance of the MvcRouteHandler object to handle every request.  MvcRouteHandler hides all the complexities of taking the requested URL, breaking it down into parts, finding the right controller in your application, instantiating it and passing it all the data it needs.

The end result of MvcRouteHandler is not what we desire. We want to return an image, not instantiate a controller and run a method.   We want to skip dealing with controllers altogether in this case.  So lets create our own route handler that we'll use instead.

To do so, we simply implement IRouteHandler, an interface exposed by ASP.Net MVC that actually inherits from IHttpHandler.  This means that what we're writing is the ASP.Net MVC equivalent of an .ashx file for a webforms app -- we're inserting our own handling module into the ASP.Net pipeline, that will handle the request much closer to the webserver/http level, rather than at the ASP.Net application level.

IRouteHandler only has one method that we need to implement, which is GetHttpHandler().

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Web;
using System.Web.Compilation;
using System.Web.Routing;
using System.Web.UI;

namespace MvcApplication1
{
    public class ImageRouteHandler : IRouteHandler
    {
        public IHttpHandler GetHttpHandler(RequestContext requestContext)
        {
            string filename = requestContext.RouteData.Values["filename"] as string;

            if (string.IsNullOrEmpty(filename))
            {
                requestContext.HttpContext.Response.Clear();
                requestContext.HttpContext.Response.StatusCode = 404;
                requestContext.HttpContext.Response.End();
            }
            else
            {
                requestContext.HttpContext.Response.Clear();
                requestContext.HttpContext.Response.ContentType = GetContentType(requestContext.HttpContext.Request.Url.ToString());

                // find physical path to image here.  
                string filepath = requestContext.HttpContext.Server.MapPath("~/test.jpg");

                requestContext.HttpContext.Response.WriteFile(filepath);
                requestContext.HttpContext.Response.End();
            }
            return null;
        }

        private static string GetContentType(String path)
        {
            switch (Path.GetExtension(path))
            {
                case ".bmp": return "Image/bmp";
                case ".gif": return "Image/gif";
                case ".jpg": return "Image/jpeg";
                case ".png": return "Image/png";
                default: break;
            }
            return "";
        }
    }
}

The above IRouteHandler is pretty simple.  Ignoring the GetContentType helper method, there's really only two things happening.  First, we check for a "filename" parameter that got passed in to our handler (more on that in a second).  If it's not there, we return a 404 response.  Otherwise, we attempt to open up the physical file "test.jpg", and stream it to the browser.

Clearly, this should be adapted to your needs by actually using the filename parameter to find the physical files on your system.   But moving on -- how do we invoke this from our MVC app?  And how do we pass in the filename parameter, of which we'd like to reroute to some other physical path?

Routing the Request to the Custom Handler

Well, this is the easy part.  Where you'd normally define your routes in Global.asax, simply use routes.Add(), instead of routes.MapRoute().  Just like this:

routes.Add("ImagesRoute",
                 new Route("graphics/{filename}", new ImageRouteHandler()));

This method of adding our route allows us to specify our custom IRouteHandler, rather than routes.MapRoute(), which by default uses an instance of MvcRouteHandler.  So now, we've defined a route that matches against any requested URL containing "graphics/", and puts the rest of the URL into the "filename" bucket of the RouteDataDictionary, and hands it off to our IRouteHandler.  This is how we pass the filename parameter into our custom route handler -- basically the same way we pass things into controllers, by defining the variables in the route pattern.

We've successfully routed all URL's containing "graphics/", which doesn't physically exist in our web application, and returning "temp.jpg", which could exist anywhere.  With a bit of coding around the file IO, you could return files from anywhere.

And that's pretty much it!  You might be thinking, "this seems like a lot of extra work just to re-route a URL to a physical file that already existed in my web app!".   If you take a step back though, you'll see the power of this approach.  What if you wanted to log every request to the original URL to a special log file?  What if you wanted to also transform the image before returning it?  Perhaps launch a system executable or asynchronously hit a web service?  What if you wanted to…?

In a nutshell, by inserting your own HttpHandlers into the ASP.Net pipeline to handle routed requests, you can code anything that you'd like to happen when a request comes in, rather than just rewriting it to some other URL.

Why do I love optimization? It's because it's the opposite of a thankless job. Everyone thanks you. Your sales team thanks you. Project Managers thank you. Executive management drools over your optimization report -- they can take it straight to the bank. Product leads take your report and put it into the release notes. Or a press release. You're the hero! And it's downright fun.

Long story short, my team was recently assigned optimization targets for our app for increasing user capacity (+30%) and decreasing startup and postback times (-20%). During the iteration, the rest of the team was sucked away to emergency projects, and I singlehandedly blew so far past the targets I couldn't even see them anymore. Final optimizations included 100% increased concurrent user load and a 97% reduction in postback execution time. Application startup time was decreased by 40%. Total code changes was 40 lines. Call it precision strike coding. Toss in one nicely formatted "before and after" optimization report, and I'd say it's been a pretty good couple of weeks.

But you need to know what you're doing, and where to get started. You can't simply sit down in front of the code and start randomly caching things or turning every '+' operator into a StringBuilder. (Note: that's not a good idea anyway). But if you get familiar with the following tools, you'll already know where to start. So without further ado…

The ASP.Net Optimizer's Toolbox

If you want to optimize, you need to have an arsenal of tools to troubleshoot and profile your app. You should be familiar with as many of these tools as possible.

1. Code Profiler

Recommended: RedGate Ants (14-day free trial, $295 to purchase)


Pretty much no exceptions here -- you have to have a profiler. It's extremely time consuming and ugly to start adding TimeSpan calculations around every block of code in your app. For the amount of time it would take to track down one slow line of code "manually", you could have run four profiler sessions and have your top ten "target list" ready to go, made yourself a sandwich and played a game of foosball. Not only that, but profilers will identify fast blocks of code that are getting executed ridiculous numbers of times, making them slow overall.

Since I've used RedGate's Ants Profiler pretty much exclusively, that's all I can recommend here, but others exist. RedGate is great at profiling code, but I find their memory profiling to be pretty lackluster, so if I need to dig into memory I'll generally fire up Windbg (see further down).

2. Application Stress Tool

Recommended: NeoLoad (10 "virtual user" Free Trial but fairly expensive to purchase)
Also good: WAST (Free)


You need to be able to load test your application to see how it performs. When does it crash? How many users does it support? How does your memory, disks, network and processors hold up? Load testing uncovers errors you couldn't even dream of by looking at your code -- concurrency issues, how your application performs when resources are unavailable, etc.

Load testing tools pose a problem however, because there is a huge gap between free tools and proprietary tools. Here's a list of some of the ones I know for Windows/IIS:

TinyGet (Free) - run some HTTP requests sequentially in a loop.  Part of IIS 6 Resource Toolkit
WAST (Free)- an oldie but a goodie -- record basic web browsing and simulate lots of users
MS ACT -- (Application Center Test) -- Next generation from WAST, allows for dynamic variables.  It comes with Enterprise Edition level MSDN subscription.  Thanks to mike for pointing it out.
NeoLoad - good bang for the buck, all the functionality you'll need for even complex AJAX applications, but not cheap and has a predatory pricing model shared by higher end software
Visual Studio Team Edition for Testers -- you can buy a lot of NeoLoad virtual users for this kind of cash.
HP LoadRunner -- you could probably hire a thousand testers, buy them all computers and have them generate load manually for what you'd pay for this kind of software.

The problem is that the free stuff (TinyGet, WAST) is next to useless for testing sessions and AJAX apps, they're just not built to handle it. I've recently gotten a lot of experience using Neoload and it's pretty good software with fantastic support behind it -- you can record complex user sessions with many dynamic parameters, multiple viewstates and have multiple recorded sessions make up a "population" of users to test your app under a broad range of conditions. It also hooks into the perfmon API to give you flexible reporting and graphs. Unfortunately they charge per "virtual user" you want to have running, and it's not real cheap. Small businesses may find it worthwhile depending on the situation. Freelancers may want to stick with WAST, look at some other options, or roll their own.

The top range stuff is for medium-very large businesses that can shell out the dough, and I don't have any experience with them. For the money, they'd better be good!

3. Performance Monitor

Recommended: Performance Monitor (perfmon.exe) (Free)
Also good: NeoLoad

At what point does your app spike the CPU? How's that CLR request queue going? What's your heap memory look like? Microsoft's perfmon API is very rich and if you don't have a custom app that hooks into it already, simply type "perfmon.exe" at the command prompt and you have everything you need in Microsoft's simple MMC app. You can monitor as many machines as necessary all in the same window or log. Experiment with recording counter log files and replaying them -- this data can be exported and included for that extra-demanding CTO. If you're unfamiliar with perfmon, play around with it -- it's not too hard to figure out even though the interface is a bit dated.

4. HTTP Recorder

Recommended: Fiddler2 (Free)


Optimizing your AJAX app? Confused about how chatty your application is being? You need to be able to see exactly what's going between client and server -- requests, responses, headers, what's compressed and what isn't. Enter Fiddler2 -- this little proxy server sits between IE and any web page and records all the traffic, and reports it for you in an easy to see format. Tip: if you're looking at your pages on your local machine, use http://machinename instead of http://localhost, since IE ignores going through a proxy for localhost addresses.

Fiddler2 is especially useful for ASP.Net apps because it's not always clear exactly what kind of HTML is being generated by webcontrols.

5. Interface Manipulation

Recommended: Firebug (Free)
Also good: Developer Toolbar for IE (Free)


Any web developer by now has heard of the Firebug plug-in for Firefox. It lets you manipulate CSS, HTML and javascript on the fly on any webpage you're viewing, complete with a javascript debugger and DOM explorer. In fact, I don't know what we did without it, back in the good 'ol Web 1.5.6.18 days. If you must develop with IE (*shudder*) you can get the Developer Toolbar for IE, which isn't nearly as good, but does the job in a pinch.

6. Debugger

Recommended: Windbg (Free)
Also good: DebugDiag (Free)


A good debugger/memory dump analyzer is probably the single most powerful tool in your arsenal if you know how to use it. Windbg will let you take a snapshot of your application as it's running or when it crashes, and you can quickly narrow down what's causing crashes, hangs, excessive memory usage, or identify potential optimizations. You can explore the runtime stacks, native and CLR, see what every thread was doing, and see what's in every memory address on your heaps. If you've never used Windbg, there are fantastic lab-style tutorials at Tess' blog at MSDN. These tutorials will also introduce you to perfmon and tinyget.

7. FXCop (Free)
   

FXCop can be a useful tool but depending on your environment, it might be more trouble than it's worth. Simply put, it scans your code looking for bad coding practices and comes up with a report about how sloppy you are. Unfortunately, some of the default rules may not apply to your development environment, but with a little effort you can certainly weed out the rules you don't need and make it more useful for your team.

8. Viewstate Decoder

Recommended: Fritz Onion's Viewstate Decoder (Free)


At some point most ASP.Net apps undergo a Viewstate optimization. Let's face it, Viewstate can be downright disgusting. If you're jumping into the middle of an application, it's helpful to have some guidance on where the hell it's all coming from. Just copy and paste it into a Viewstate decoder and you might find a ton of clues.

9. Text editor

Recommended: Ultraedit (45 day free trial, $49.95 to buy)
Also good: Notepad2 (Free)


As every experienced coder knows, sometimes, you just don't want to look at something in your IDE. You just want to open a file fast and be done with it. I've used UltraEdit for a long time and it has great features, useful for optimization. For example, you can copy a recorded request from Fiddler, paste it into Ultraedit, and immediately count how many times your ultra-long image pathname occurs, and immediately know how many bytes you can shave out of your file. It has quick and easy syntax highlighting for pretty much any programming language, line numbers, and tracks the file and asks to reload it if it detects changes. It also detects blocks of code or xml for expanding/collapsing, and hundreds of other features.

Although I didn't include Lutz Roeder's Reflector in the list since I don't find that I use it that often when I'm debugging, it's something you should always have for easy reference, especially if you're dealing with unfamiliar assemblies.

Good luck optimizing! Remember to spellcheck your optimization report, and don't forget to put in a one page executive summary of what a hero you are.

Viewstate and lifecycle events are still very confusing for new ASP.Net programmers. There is no easy way for them to immediately "get it" -- they have to spend the time in the trenches, watching their data disappear on post back, or double-bind, and flail around with building and rendering their own web controls. They have to see the DataGrid spew its html diarrhea and spend hours customizing it. They have to have that client ask them "what the hell is all this javascript, and why are the pages so big?" and figure out just what the heck all that gibberish on their pages are.

Moving up the experience chain, Viewstate and lifecycle events represent a significant amount of design and front-end time on a web application even for those that have been doing it for a while. You have to balance your state management with your html optimization, caching, and application maintainability. Often you have to build your own state-tracking structures or extend existing ones. You have to carefully consider whether to roll your own custom controls or buy third party interfaces and rely on their javascript and state programming (or maybe their support team!) And for very simple "read-only" web sites, viewstate just gets in the way.

So in summary, Viewstate and lifecycle are still be a pain in the butt, and still represent hurdles for new programmers. Years ago, it was worth the annoyances and problems, because you could write strongly typed, object oriented portable code without getting lost in folders and folders of scripted sites. So why might it be dying? Well…

The first item on the agenda is Silverlight. ASP.Net represented significant advantages for writing portable code that was closer to classic desktop programming, as it abstracted out much of the xhtml. But now I've seen web application developers swoon over Silverlight. If their reaction is any indication, and the amount of momentum that Microsoft is putting into WPF, many shops are going to give up programming their internal or non-public projects in ASP.Net and move to Silverlight instead. I'm personally still skeptical about Silverlight's market penetration, as there are many gaps it doesn't fill for content publishers. But it's not a minor consideration.

Second is the new ASP.Net MVC framework. MVC is an old model that's rapidly gaining traction in the web world, and with the introduction of the ASP.Net MVC framework, it is hard to see any clear advantage to the older webforms model. From Scott Guthrie's Introductory MVC post a couple months ago:

To help enforce testability, the MVC framework today does not support postback events directly to server controls within your Views. Instead, ASP.NET MVC applications generate hyperlink and AJAX callbacks to Controller actions -- and then use Views (and any server controls within them) solely to render output. This helps ensure that your View logic stays minimal and solely focused on rendering, and that you can easily unit test your Controller classes and verify all Application and Data Logic behavior independent of your Views.

And finally, we come to REST, another model that is gaining traction. True REST and webforms are mutually exclusive since REST involves heavy reliance on mapping resource locators to known states of an application. This model has lots of advantages for web services and data-based applications, especially in the realms of testing, while ASP.Net Webform applications are often built around one URL for many states, using Viewstate and Session as your state map, which are of course lost between sessions and server restarts.

So long story short… I think we're seeing the beginning of a new paradigm. In 5 years, will anyone still be developing with true ASP.Net Webforms? It will be interesting to see!

So from the last few weeks, I thought I'd share some tips I've learned to make writing Selenium tests easier on yourself.

1. Make a GUI Component map

The first thing you should consider is mapping all your GUI elements to strongly typed objects, or at least a dictionary of named XPath strings. It is much easier on everyone if they can read your code and see something like
Selenium.Click(UIElements["LoginButton"])
rather then something like
Selenium.Click("//div[@id='LoginContainer']/table[1]/tbody[1]
/tr[3]/td[2]/a[1]/img[1]")

Hand in hand with this tip, I'll remind you to use Best Practices and get your developers to put in an ID for any web page element that will be interacted with Also, you can check out the Selenium extension called GUI_Map if you're looking to extend the Selenium core for your environment.

2. Fix the timer code!

The code that the Selenium IDE generates for a timer loop is terrible! It loops from 0 to your timeout number, checking the condition and then sleeping for one second. This assumes that the loop itself has a negligible execution time, which is untrue in many cases. I've run into situations where for whatever reason, the timer loop runs very slowly depending on the XPath you're checking against. This means your 60 second timeout actually takes wayyyy longer, which is very annoying. Use this code instead to more reliably measure elapsed time:

>> show as plain text
C#:
1. DateTime start = DateTime.Now;
2. TimeSpan ts = DateTime.Now.Subtract(start);
3. bool bFound = false;
4. do
5. {
6.     try
7.     {
8.         if (_selenium.IsElementPresent(elementName))
9.         {
10.             bFound = true;
11.             break;
12.         }
13.     }
14.     catch (Exception)
15.     { }
16.     Thread.Sleep(1000);
17.     ts = DateTime.Now.Subtract(start);
18. }
19. while (ts.TotalMilliseconds <_waittime) ;
20.  
21. if (!bFound) Assert.Fail("timeout");
3. MouseDown() + MouseUp() is better than Click()

I've found that in many situations a call to Click() won't work, even if the Selenium IDE generated the code. This is especially true for block elements like table cells that you've styled to be clickable. Just give up and use a call to MouseDown("element") followed by MouseUp("element"). This works great in almost every situation.

4. Simulate Click-Drag with MouseDownAt + MouseUpAt

I also searched long and hard for a Click-drag method for Selenium until realizing that this can also simply be done with MouseDownAt("elementName", "x1,y1") followed by a MouseUpAt("elementName", "x2,y2"). Handy if you're testing on-screen drawing or selection tools using click-drags.

5. Use the Command Pattern

One of the things the testers appreciate most is that my API handles all the overhead in their tests. Typically you'll want to split your integration tests into multiple parts, so any given test run would be composed of several tests, each of which runs a sequence of selenium commands. In order to reset our test environment for each test, I made heavy use of the Command pattern to implement file undo stacks, reversible web-steps, etc. That way, testers can go deeply into a sequence of commands and simply call the reverse of each command in the stack to back them out to where they started from. Very useful when testing anything that modifies configurations, test data, etc.

6. Modal Dialogs are a show-stopper

There's no getting around this one. Browser dialogs such as the file download dialog are not testable in Selenium. There is work being done to allow this in the future, but currently you're out of luck.

7. Access Javascript Variables in your page with getCurrentWindow()

If you're using WaitForCondition(), you can use the following snippet to access the DOM for the page that Selenium is running:
selenium.WaitForCondition(
"this.browserbot.getCurrentWindow().imgloaded == 1", "15000"
);
This is handy for executing existing javascript functions as well as checking variable values.

8. Selenium IDE is not your friend: Re-use code to reduce fragility

A fundamental drawback to using a GUI direct-testing tool is the reliance on locators for GUI elements. If your locators change, your tests break, even though functionally the app might still be in perfect working order. As well as using Best Practices to make your tests as robust as possible, you need to centralize your locators (see Tip #1) and build a library of utility functions to re-use. Having 15 wait-for loops in a test or having the same navigation routines in multiple tests is hideous, not maintainable, and very fragile.

9. Use Firebug + Selenium IDE for XPath finding

While the Selenium IDE will choose the shortest XPath it can find when it generates your test code, often it isn't what you want. If you don't want to edit the default behaviours of the IDE tool (which requires some javascript tinkering), I find it helpful to just use the Firebug extension for Firefox and hit F12 to bring up Firebug when the Selenium IDE won't generate a good locator for you. Use firebug to view the element and determine the XPath you need, replace it in the Selenium IDE, and continue along your merry way.

10. Use the following code to test for all finished callbacks

If you're making use of a framework that is using the ASP.Net 2.0 Callback architecture, this little snippet can save you a bundle. The key to AJAX testing with Selenium is making use of the various WaitFor...() methods. For a normal AJAX request, you would just do a regular WaitForCondition or WaitForElementPresent - so what's different about some callbacks? If you have a Callback chain - i.e., one callback has a result that sets off another callback - you can't use WaitFors to tell when they're done. A WaitForElementPresent on something that is changed later on in the callback chain will not work, since the element is present and sitting there while the first callbacks are executing. A WaitForCondition might work, depending on the specific situation, but generally it's not easy to inject a semaphore around some callback object without making the test very fragile, and having to write code for multiple situations in your app. And of course using Thread.Sleep() slows down your test unnecessarily and isn't reliable. What we really need is a reliable generic method to check that all Callbacks are complete before we start Asserting that everything worked out. So use this:

WaitForCondition("var finished = 1; for (var i = 0; i < selenium.browserbot.getCurrentWindow().__pendingCallbacks.length; i++) { if (selenium.browserbot.getCurrentWindow().__pendingCallbacks[i] != null){ finished = 0; } }; finished == 1", "15000");

This is a semaphore around the ASP.Net __pendingCallbacks array that waits for everything to finish up and returns true when all callbacks are complete. It times out in 15 seconds (you can change the 15000 parameter to any timeout length you'd like).

There it is - 10 tips for happier test writing. Hope it helps some people out.

Now, the cleverer ones amongst you will know that Apache Benchmark, or ab, will do pretty much the exact same thing, plus much more. This is where I was planning to get my first batch of results from. But something has happened that is leaving me puzzled as to how I'm going to make these tests fair.

I ran a few benchmarks against a basic PHP page, and it was pretty consistent, within the realms of what you'd expect for a page just coughing up the same content over and over. When I ran the same benchmark against a similar .aspx page however, things were not consistent!

Mono benchmarks - an anomaly

Without going into a long post about what all results were, here's a brief summary. I originally noticed the problem when I ran ab -n 1000 -c 10 [url] from a remote machine that is on the other side of the country. ab was given a PHP URL and an ASP.Net URL for the test server here on my home network, and dutifully returned results for each. The PHP page was giving me results similar to the following (results in seconds for total test time, rounded for brevity):

75, 75, 74

Looks good. Kind of what you want to see in a benchmark. Predictable load times under a given circumstance means your application code is working predictably as well. I ran three tests and averaged the results. So what did I get from Mono? I restarted apache, hit a page to get rid of the initial .Net load time, then ran three tests. Check this out:

77, 77, 100

I thought that was kind of weird. Maybe the server was under some sort of load I didn't know about, so I thought I'd chuck the third benchmark as anomalous and run some more:

95, 107, 92, 106

Now I had a case of the WTFs. Thinking something was wrong, I rebooted apache (and hit a single .aspx page for the initial .Net load). Then I ran some more tests:

restart, 78, 79, 92

There it goes again! I switched to testing on the server machine itself under my desk to get rid of any network latency that might be occurring cross-continent. I ran some PHP benchmarks to see what I would get.

51, 51, 66, 52, 51, 51, 51

Looks good, save the spike in the middle. Back to Mono:

restart 56, 58, 61, 62, 68, 62, 63, restart, 57, 61, 61, 63, 67

WTF

It quickly became evident that the Mono environment is accruing some sort of overhead the more I pound on it. And it's not getting away from this overhead either. I left it alone for awhile to gather its thoughts (and maybe its garbage) while I took a break, but when I tried again it still showed much higher benchmark times than it would right after a server restart. The conclusion I came to over another hour of testing is that Mono would never serve pages as fast as the first benchmark on subsequent benchmarks.

This has delayed my actual collection of benchmark data between PHP and Mono ASP.Net, as I don't feel that it's a fair comparison between the two if Mono is accruing performance penalties the more I use it.

I'm going to have to research this a bit more. Maybe it's my configuration, maybe it's Apache, maybe it's mod_mono, maybe it's something wrong with the .aspx test page, maybe it's a spooky goblin. Maybe it's Mono itself. I don't have enough information at this point to be sure. I'll have to try to narrow this down, or continue testing knowing this limitation.