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.

You see, I work on a pretty large and complex ASP.Net webforms product, and tests were introduced late into the development cycle of the initial release.  We favored integration testing with real data sources over actual unit tests. While I did write some tests, I knew that our product was not very testable by design.

Recently we put together a public facing API for programming against the product, that we were able to build from scratch.  This was a natural opening to apply test driven practices and start building unit tests from the get-go.  Due to the service oriented nature of the data that the product consumes, I soon found myself realizing that I needed mocks in a big way.  I gritted my teeth and dove head-first into Rhino.mocks.

Several weeks down the road, it was obvious that Rhino just isn't right for our environment.  The learning curve is too steep to win quick success with all our developers (and therefore by extension, our project managers).  I began looking for another framework.

This led me on a frustrating research mission to find the differences between frameworks without actually trying them all. Due to a lack of in-depth comparisons of the actual capabilities of the various mocking frameworks, I've ended up putting together this chart.  I'm hoping it helps some people.  My interest is very high in this arena, so I will be keeping it up to date.

(Just for interest's sake -- we ended up choosing Moq, due to the ease of the API.   The philosophy of Moq jives perfectly with our relatively fast-paced and efficient development environment.  We don't care about purism -- we care about getting it done.)

Other Notes

The above observations were gleaned from many web pages, documentation repositories and blog posts, and reflect my limited understanding of each framework.   There may be errors.  If you think I'm wrong, or you can think of other capability aspects that I've overlooked, please let me know!

I made a tongue-in-cheek comment in another question thread calling PHP a terrible language and it got down-voted like crazy. Apparently there are lots of people here who love PHP.

So I'm genuinely curious. What am I missing? Why makes PHP a good language?

The article lists a dozen or so "flaws" with the language, and then continues:

Worst of all, PHP convinces people that designing web applications is easy. And it does indeed make much of the effort involved much easier. But the fact is, designing a web application that is both secure and efficient is a very difficult task.

By convincing so many to take up programming, PHP has taught an entire subgroup of programmers bad habits and bad design. It's given them access to capabilities that they lack the understanding to use safely. This has led to PHP's reputation as being insecure.

Are the flaws in PHP really any different from any other language?

I'm a C# programmer, and I have to disagree with what some of what the original poster asserted were flaws with PHP.  Overly broad implicit type conversions?  Too easy to couple presentation with logic?  Heck, those are the reasons it's so popular in the first place!  Making web programming easy is a flaw?  Wut?

After wrestling with the back and forth in that discussion, I came to a simple conclusion.    This person has fallaciously concluded that PHP is a bad language based on his perception of its compliance with ivory-tower, computer science academia concepts.   Most of his criteria could basically describe Perl, Javascript, VBScript, heck, even VB6, HTML and C.

Of course PHP isn't a horrible language.  It's simply a tool, and based on its wild popularity and simple learning curve, only a fool could conclude that it was a bad one.  Even if it breeds more "unsafe programmers" (which I doubt highly), it's simply not the language's responsibility to restrict what you can do just because you might do it.

Every programmer should be able to see that.

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.

Sometimes it's easy to forget that HTML is just one type of XML, and hence you can utilize the System.Xml library for fun and profit with your HTML. System.Xml is full of powerful tools to manipulate well-formed documents, and you really don't need to know much about XML to leverage it. With two simple lines of code you can have a document loaded into a data structure that has powerful manipulation methods that allow you to do complex tasks. Such as generating a table of contents, for example.

Blake phoned me last night very frustrated after having spent a couple hours scouring the 'tubes for some kind of tool that would take his marked-up html document and generate a table of contents from the heading tags in it. He started asking my advice about a C# program he had downloaded. It included three forms and over 1000 lines of code, and purported to do what he needed. Except it didn't... it just kept crashing, and couldn't handle certain nestings of tags, etc. etc. One look at the code made it pretty clear why... some kind of home-brewed tree structure peppered with variables like "treeUp, treeDown, treeRight, itemBegin, itemEnd".... bleeargh. XmlDocument to the rescue!

In 45 minutes I had a program whipped up into a console app that did exactly what he needed, and it was essentially only 60 lines of code (plus some jazz for error handling/argument passing). Let's take a look:

So in line 3, we start looping over every node (i.e. html element) in the document. Line 5 checks to see if the current node is a header tag with a simple Regular Expression. Lines 11-34 control the indent level of the TOC's html output - we use one <ul> level for each header level. (So an h5 tag is nested in 5 <ul> tags.) Line 37-38 adds some html output for the TOC for the current node, namely we create a TOC list item. Finally, lines 41 and 42 modify the original XmlDocument object by adding an anchor tag to the html of the current node. Then we recursively call the function again with the current node's children. The last bit of code polishes off our TOC output at the very end of our recursion.

(At this point, real purists might interject with the fact that 10 lines of code and an XSLT stylesheet could do the same thing; I'd agree, except in practice I find that executing simple loop-driven tasks with XSLT to be quite cumbersome, and I doubt I could do anything with XSLT in 45 minutes.)

So to use the function above, simply harness the raw power of the System.Xml.XmlDocument object, like so:

Assuming your HTML is well-formed, you can now pass htmldoc.ChildNodes and a StringBuilder into the recursive function above, and your StringBuilder will come back full of HTML table of contents goodness. Additionally, your XmlDocument variable will have the corresponding anchors added to the header tags. Just simply output your StringBuilder and XmlDocument to a file, and voila! Instant HTML table of contents! (Might look something like below:)

All that in less than 80 lines of code, 45 minutes, and no XSD's, XSLT, or really, any XML at all. XmlDocument.Load() is simply one of the greatest functions in the .Net framework. Instant document object with an implicit tree structure.

Download the code here: HTML Table of Contents Generator. It includes a binary .exe file in the "bin\Release" directory, so you don't need Visual Studio if you just want to run the above program Simply call htmltoc.exe infile.html, and you'll have TOC.html and OriginalWithAnchors.html outputted. TOC.html contains your nicely formatted table of contents, with links to all the anchors in OriginalWithAnchors.html.

Look at this post on "Real World" for crying out loud. Peter Seale has a rebuttal that does a great job at summing up my thoughts about the article, but one thing that continually fails to be addressed is "why". Why Silverlight? Why do we need it? Do we need to make web apps behave like desktop apps? Maybe developers do.... but the average web surfer today is a different story. In fact, I'd go so far as to say that Joe Web will likely resist Silverlight unless it can be introduced seamlessly, won't degrade web performance/user experience, and user interfaces are developed properly... unlike when Flash was first introduced. The average web surfer expects a web page to act like a web page, and you have 4 seconds for it to load if you want to keep them there. When was the last time you enjoyed hanging out at an all-flash web site? And maybe last but not least, if a high-profile security exploit were to be associated with Silverlight at this juncture, it might be a lot of trouble for corporate adoption.

So if Silverlight is going to succeed, there is a lot to overcome. And maybe it's great for app developers, but content publishers still have many unanswered questions and it doesn't look like there are many answers right now. Not to mention, the demo applications that I've seen have run like turds on any machine older than 3 months, and the 1.1 Alpha release (1.1 alpha??) has drawn a lot of developer ire.

Don't get me wrong - I heartily approve the concept. The point is, Silverlight needs to satisfy a lot more than just application developers. RIA's make up a small portion of the internet. The real web runs on content, from the Library of Congress down to your dog's Facebook application. And every time I hear Silverlight, a little voice in my head whispers "ActiveX ActiveX ActiveX"... I guess I'm still getting over that nuclear disaster.  This reaction to Silverlight just reeks of the reaction to Longhorn during the first couple years of feature marketing (WinFS!), and we all know what happened to Vista.  I'm going to sit on the skeptic fence for a little while longer.