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.

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.