I’m presenting tonight at the Gateway JUG on “Web Acceptance Testing with Selenium”. My slides are up here. If you want to know more about Selenium you should come…or just check out their site if you can’t make it to the meeting 
Selenium Presentation
August 1, 2006 by jamesBenjamin Paul Stubits
May 18, 2006 by jamesThank you Benjamin for your amazing strength and for the love you brought my friend.
Automated Tests with Junit + Selenium + JsUnit
March 21, 2006 by jamesI plan to have a more cohesive post on the process I went through and some of the specific tweaks I had to make…but right now excitement has the best of me and I’m going to let the keys fall where they may.
Recently, the project I’m on REALLY needed some automated testing. We had (have) a rich web-app (ajax/dwr) and were beginning to feel very uncomfortable without tests…a bit like going “without a net”. We had been researching Selenium for the integration/ajax testing and jsunit for some (although admittedly very few) of the javascript objects/classes/widgets we had written, but nothing automated. It was time…so I dove in.
To make a long story short, what I have today is Selenium integrated jUnit tests. The jUnit Tests look like this:
public class SomeScreenTest_UT extends BaseSeleniumTestCase{
public void testCanSearchOrders(){
open(”/products/search”);
assertNotVisible(”searchResults”);
type(”searchField”, “amber bottles”);
click(”searchButton”);
waitForValue(”searchStatus”, “complete”);
assertText(”resultsMessage”, “Found*”);
}
}
Upon execution, a browser will open to the SeleneseRunner.html and will begin running the tests. It is really pretty sweet. The base test case we’re using will open the login page and login first on setup. Then the tests do their thing and if a selenium assert or command fails, then the junit test fails.
I managed to get this working with Selenium 0.6.0. I wound up implementing a SocketBasedCommandProcessor (can you guess what it does?) as well as a client to go with it. Extended DefaultSelenium to have SeleniumDriver (I needed to have more control over the url the browser would open…and I didn’t like the name). Also implemented a SeleniumDriverServlet to go along with it (the browser talked to the servlet…which talked to the processor via the client). I was pretty proud of it…even followed (fairly) strict TDD.
After implementing all this, I got to REALLY pouring through the Selenium code (last night) and noticed a few interesting classes…namely CommandBridge and CommandBridgeClient. In short, they do (or appear to do) what my implementation does, just without the sockets. It would have been REALLY nice to know about them first. I honestly felt I was tricked 
The docs are aparenly out of date and some of the examples refered to code that has been moved. When I couldn’t find them, I though they were just making suggestions So one strike against the docs (btw not even the wiki has any mention of them). Even when reading the package structure, it wasn’t at all clear to me that the ‘outbedded’ package and the CommandBridge (which IS a servlet) were what I needed to get a servlet that talked to an external tomcat process…especially when nothing from the actual servlets package seemed to fit. Go Figure.
But after reading the forums, I’m not so sure the CommandBridge code even works. Aparently the “driven” stuff is undergoing a huge overhaul and is now going to be called “selenium remote control”. Which is good really because these guys have some good stuff under the hood and it just needs to be a bit easier to use. It could use some better names, and packaging…and definitely better docs, but it is still some great work.
Also, just today got Selenium to drive the jsunit tests for the app. That was cool too…we needed jsunit to run in the build as well and I figured we already had this selenium setup, why not have IT drive the jsunit tests too. It took some tweaking because jsunit expects to be the top level frame, but it worked.  I should mention that I do prefer to have jsunit run without need of the server running…and we still have that ability, this was just an easy-ish way to get it working with something we already had, just for the continuous integration. I also know that jsunit has a server bit that ant can drive, but we wanted to be able to make it work just by running the junit test, this gives us that…no need for ant to kick anything extra off, just make sure the local server is running, which it usually is). The test suite that selenium ‘drives’ is actually a jsp (so there IS one benefit to having the server running) that will scan the js folder for all _UT.html files, and adds the path to them to the test suite.
Gentleman’s Privates
February 25, 2006 by jamesIn Javascript, you can have true private methods and fields, but it comes at a cost…both a readability cost and a performance cost. It basically involves creating closures in the constructor. Those closures are attached to ‘this’ reference and since they are closures defined in the scope of the constructor, they have access to any of the constructor’s local variables. An example may prove useful:
function Foo(){
var privateField = “Only setPrivate and getPrivate can see this field”;
this.setPrivate = function(value){
privateField = value;
}
this.getPrivate = function(){
return privateField;
}
}
I first learned about this over at Douglas Crockford’s site (this guy knows his stuff…read it!). He as great explanation of private members in javascript.
At the moment (and I’m sure this can change) I feel this is a bit overboard for most cases. I think I may be more turned-off by the readability…I just can’t bring myself to be ok with having the methods defined IN the constructor. I understand this is the only way to have TRUE private members…but I’m thinking that I’d be ok with Gentleman’s Privates. That is to say, using a notation that tells the user (developer using, reusing, extending or otherwise interacting with the class or an instance of the class) that the variable is meant to be private…”so, be a gentleman and don’t access it directly”. Sure, this leaves the door open for abuse…breaking encapsulation. But if the convention is known…then the developer KNOWS they shouldn’t be directly accessing the variable (even though the language doesn’t enforce it). And by doing so, they run the risk of becoming too tied to that implemenation of the class.
Naming conventions for private members is done all over the place…even in languages that support true private members (no I don’t). I can’t find it with a quick google, but I’m sure I first heard this approach in reference to Perl. It was something to the effect of describing Perl as a “Gentlemen’s Language”. Basically meaning that the language didn’t enforce any access restrictions, but the developers were ‘gentlemen’ about it, and followed the rules of the naming conventions. The typical convention for private members (as I understand it) is to prefix the variable with an ‘_’ character. In my experience, many developers understand this convention.
I prefer the Gentlemens approach to private members in javascript.  I don’t want to get hung up on trying to lock my object/class down to prevent any abuse: jumping through hoops trying to get access priveleges that are not enforced by the language. Let’s just be gentlemen about it.
Ok, all that said, I was thinking a bit about the naming convention itself. The ‘_’ prefix is well known, so it’s tough to just say ‘lets change it’, but I’m thinking…’lets change it’. How about ‘ _’? That is SPACE-Underscore…as a prefix for private members. This forces the developer to access the member via the bracket notation: obj[' _somePrivate']. This has a few benefits in my mind. First, it isn’t natural which means you’ll have to think about it and say “well…it IS private…maybe I should try something else”. Second, its not pretty…so a developer may decide to modify the design (if its his code) so that the member is exposed, or it supports whatever the caller was trying to do via a new method.
The negatives are actually the same as the benefits…but the caller is the class code itself. So the class has to access its private members through the same bracket notation, which is still not natural, and still not pretty. Given that the private members should (by definition) only be accessed by the owning class, this may seem like just an annoyance and may find developers quickly abandoning it.
In the end…I guess I’m up in the air about it. I like that it will make it more work for developers to access it when they shouldn’t (from outside the owning class)…but I don’t like that it will also be more work for developers to access it when the can/should (from inside the owning class). And in the end, maybe ‘_’ should send up the same flag to the developer as “[' _']“.
What are some of your thoughts?
Laying tile
February 25, 2006 by jamesWe managed to make some headway last night laying the ceramic tile. My hands still have a bit of stubborn tile adhesive on them as I type. The base-boards were pulled as soon as I got home from work. I’d planned on going to a coffee shop and working on my presentation, but I figured I could do that Sat and Sun.
Once the baseboards were up, it was time to think about where to lay the first tile…and how the others would fall around it. This took a long time. Its tough trying to map out the tile layout to get as many full tiles as possible (and keep them straight!). We finally decided to snap a chalk-line and I started tiling while Aislinn went out to get more stuff for showing the house (vases, borrowed rug, paintings…stuff we just don’t have, but make the house show better :)).
I managed 30 tiles before she got back. I only had 4 that had to be modified. 2 just needed a corner chopped…and 2 needed a notch. The notches sucked. I didn’t want to drag out the wetsaw with the boys sleeping (it was 10 by now). I managed to chop the corner off of both…and ‘liquid-naile’d them both back on. It worked out well.
So now I’m here at the coffee shop working on my presentation. (And blogging a little).
Class.js - third time is the charm
February 24, 2006 by jamesSay you want to override a method by adding a new impl directly to the instance. callSuper should be callable from that new overriding method and it should result in the closest ancestor impl being called…even if it only has to go as far as the instance prototype (technically, the instance’s constructor’s prototype). Well…the code I had up wouldn’t really support that. It would skip over the instance prototype. The latest will support this.
Maybe I should start versioning I definitely need to have tests.
Bug in Class.js
February 23, 2006 by jamesFound a bug and fixed the version that the previous posts point to: Class.js
Basically, the callSuper would not work if the method was not implemented at the beginning of the chain. For example if you have classes A, B, and C, (where B extends A and C extends B) and B and C implemented a toString then calling toString on an instance of A would result in an infinite loop. With the updated code, an array is built to represent the prototype chain, and that array is traversed IN REVERSE until it finds the calling function. Then it grabs the NEXT prototype in the chain and executes the method if it exists. No need to search and keep digging throught the chain to see where it is implemented…because the built in chain traversal will do that for us (pretty much the same reason the bug was occurring).
Anyway code is fixed and re-posted.
Finally Posted Code…and I’m moving
February 23, 2006 by jamesI got the Javascript Inheritance code uploaded: Class.js
I’ve been keeping pretty busy getting our house ready to sell. About 2 weeks ago we found a house in U. City that we love…put an offer on it and it was accepted. Pending all inspections and such, we close March 30. So…we now have to move up our plans to sell our own house and do a few years of upgrades and painting in a week or so. So far Aislinn has been really busting her butt painting EVERYTHING and I’ve been remodeling the master bathroom and fixing random other things (and breaking others :)). I’ve gotten pretty comfortable with plumbing too. Then there is the presentation on OOJS on Monday. It’ll be fun, but so far, finding time to prepare has been almost impossible.
SO, about the code (if you haven’t been following the posts on it). The Class.js file provides an implementation of Classical Inheritance for Javascript. It does not involve newing up an instance of the superclass to set as the subclass’ prototype…I really didn’t like that approach. The implementation still builds a nice prototype chain though. It basically create’s an inline function…then sets that function’s prototype to the superclass prototype. Then it news up an instance of that inline ‘class’ and sets the subclasses prototype to that instance. So the prototype chain for instances of the subclass still actually contain a reference to the superclass’ prototype.
The code also adds a callSuper method to the subclass’ prototype. callSuper can be called from anywhere in the subclass and will result in a call to the superclass’ implementation of whatever method the call resides in (actually…it will find the first implementation further ‘up’ the ancestor chain…not neccessarily in the superclass). So, effectively, it knows how to find the overridden version of the calling method…and calls it. For Example:
function Shape(){
}
Shape.function.toString = function(){
return "Shape";
}
function Square(){
}
Class.extend(Square, Shape);
Square.prototype.toString = function(){
var str = this.callSuper();
return str + ': Square';
}
Screen Reader Form Navigation Events
February 9, 2006 by jamesThe guys at Access Matters have put together a sweet chart that shows what form navigation events are fired when using screen readers . Man I wish I’d had this at the USPS.
A Stab At Javascript Inheritance
February 8, 2006 by jamesHere is the working code for implementing an inheritance model in javascript. Most of the code is actually for handling the callSuper functionality (calling an overridden method in the super class). The actual subclassing code could be reduced to 4 lines if that bit were removed. Just highlights the “are we sure we need this” question. But its DAMN cool…and I had fun, so it was worth the time.
This script requires arguments.callee.caller to work…that is the magic the code uses to figure out where in the prototype chain to begin the search for the super class’ implementation of the method currently being called. There were some minor tweaks I had to do to get it to work in IE, but it works. As a bonus, calling the ‘callSuper’ method from a constructor will work too.
I’ll probably wind up putting this in a library sometime…I just wanted to get it here and get some eyes on it. Enjoy
Update: I removed the code because it looks horrible on here…I’ll upload and provide a link when I have proper access.
Example Code…this is sickeningly basic…but its what I used while I was putting this together. I’m not sure why I didn’t fire up jsunit to do this thing right (tdd). Oh well…I blame the insomnia.
function Shape(){
this.shapeCalled = true;
}
Shape.prototype.toString = function(arg){
return ‘Shape ‘+arg;
}
function Rectangle(){
this.callSuper();
this.rectangleCalled = true;
}
Class.extend(Rectangle, Shape);
Rectangle.prototype.toString = function(){
var mssg = this.callSuper(’test from rectangle’);
return mssg + ‘ : Rectangle’;
}
function Square(){
this.callSuper();
this.squareCalled = true;
}
Class.extend(Square, Rectangle);
Square.prototype.toString = function(){
var str = this.callSuper();
return str + “:Square”;
}
Update: Finally posted the code here: Class.js. Getting a house ready to sell will keep you busy
