Blogbody

Wow - this is embarrassing. Another one of those "I can't believe I haven't posted in so long" posts. But really, it's been 5 months since my last post, and 7 months since my second to last one. Ouch!

That is going to change, especially because I little side project I have going on involves a lot of blogging...

As for what I've been up to...

• Got married a few weeks ago
• Sold my company earlier this year (I don't think I ever actually blogged that - whoops!)
• Been traveling a lot to Boston (50% of the time)
• Speaking at various conferences (The Ajax Experience, STPCon, StarWest, etc) - mostly QA-related stuff
• Not too involved in Struts and OpenSymphony, but I hope to be again soon
• Still fairly involved in OpenQA

I think that's it. More posts soon...

Posted by Patrick Lightbody at 11:34 AM | Permalink | Comments (1)

Does anyone know of a simple, standalone cross-domain XHR interface that allows for the ability to swap between a real XHR implementation and a cross-domain, iframes-based implementation?

I know Dojo and DWR, among others, have them, but they are all part of a larger framework. Because this is going to be used with Selenium, which needs to avoid polluting common popular JS namespaces, I'd prefer to find something that is standalone.

I'm very surprised one doesn't pop up when I search google.

Posted by Patrick Lightbody at 08:16 PM | Permalink | Comments (2)

Great work from Ted Husted...

Apache Struts 2 from Square One:

Ted Husted has put together an impressive training course together for Struts 2 called Apache Struts 2 from Square One. He's released an initial version of the 127-page PDF on SourceForge.
w
p. (Via Raible Designs ~ We Build Web Apps.)

Posted by Patrick Lightbody at 05:21 PM | Permalink | Comments (0)

While I'm on my posting blitz, I thought I'd take a moment to recognize that Struts 2.0 is GA and out.

I upgraded HostedQA to Struts 2.0 a few weeks ago and it was wonderful. I think I might even switch Able back to using it - if I get the time.

But mostly, I just want to say to the guys that made this happen (Don, Ted, Toby, Rainer, and everyone else): thank you for all your hard work.

It's truly amazing to see a project I helped grow over the last few years become so widely distributed and backed up by an amazing team. I only hope I can be more involved in the 2.1 release!

Posted by Patrick Lightbody at 08:50 PM | Permalink | Comments (1)

Why IntelliJ IDEA Customers Keep Coming Back:

Brian Pontarelli has a passion for the keyboard and makes some good points about usability and support in regards to Java IDEs, specifically IntelliJ IDEA and Eclipse. The comments after the main post are especially interesting, such as where some commenters argue over whether a reported issue counts as either a severe bug or a missing feature. I mean, come on. Does it really matter? The point is that it interferes with Brian's experience of usability and productivity. I've been saying it for a while: It's not about feature lists, it's about usability and productivity. You won't find usability or productivity on a feature list, but it can easily be the most important deciding factor on whether or not to choose one piece of software over another. JBuilder was marketed on the length of its feature list, and look where it got them.

(Via idea.log.)

Spot on. Feature-for-feature, Eclipse has most of what IDEA has. Most of the same refactoring, most of the same plugins, etc. But it doesn't have the intangibles that don't fit on a feature list.

I was just demoing IDEA to a coworker (who is an Eclipse user) and he was very impressed at the subtle things I showed him that Eclipse just completely glosses over:

• Intentions everywhere: see an error or warning? Press F2 to jump the cursor there and press Alt-Enter to bring up a toolbar that can usually fix it immediately. For example:
  • A variable not being set anywhere? Generate a setter!
  • A variable not being read anywhere? Generate a getter!
  • A parameter not being used? Assign it to a field and/or create a new field!
  • A private function not being used? Delete it!
  • A method call not matching the args being passed in? Change the signature!
  • A method doesn't exist that is being called? Create it!
  • etc etc - the list is literally hundreds and hundreds of little nuggets like this
• Smart code completion: Eclipse and VS.NET have basic code completion that offers up the list of variables in scope. IDEA goes so much further. In addition to type-specific code completion (only show things that are actually type-safe), it will even suggest variable names and other values based on your usage patterns in the past.
  • Do you always name your ProductManager variable prodMgr? IDEA will notice that and start suggesting that as you code complete a new variable definition.
  • Editing an XML file? IDEA will see the unique words and allow you to press ctrl-space and prompt you for those words. Perfect for configuration files where you often repeat the same strings several times.
  • The above also works in i18n resource bundles, even for the values of the keys. Just today "foo.desc" expanded to "foo.description" and "Desc" expanded to "Description". Once you're used to it, everything just flows..

There are a ton more examples I could provide, but the general rule of thumb is that while most IDEAs might match it feature-for-feature on a check list, none go nearly as deep. And it is that depth that makes IDEA users so much more productive.

Posted by Patrick Lightbody at 08:06 PM | Permalink | Comments (0)

Testing Ajax?:

I ran across an interesting article entitled “Improving Test Coverage of Ajax Applications” in which the author likens the challenges of testing Ajax applications to that of testing traditional GUI apps. While some newer frameworks (like Selenium) are positioned to actually verify Ajax-ian behavior, they can lead to a false sense of security because of the complexity associated with the combination of actions in using a GUI.

(Via Test Early.)

I posted the following comment to the entry above, but I think it important enough that I bring it up here as well. I'd be interested in hearing about ideas that can help make expressing tests for AJAX applications easier:

Absolutely - Selenium and other tools are now available to help, but there are still real challenges in describing these new types of interactions. The old-school tools (SilkTest, QTP, HttpUnit, etc) either didn't understand the concept of multiple user transactions in a single page or didn't have the technology to deal with AJAX at all.

Selenium helps with the AJAX/multiple user transactions issue, but it still requires testers to express the desire to "click on button X, wait for Y to appear" in their tests. I think there is still room to make this easier to understand and test against, possibly by integrating with AJAX and/or web-based frameworks, and thereby understanding the interactions at a deeper level.

Posted by Patrick Lightbody at 07:56 PM | Permalink | Comments (0)

Don Brown has a nice piece on the history of Struts 2. Check it out!

Posted by Patrick Lightbody at 11:17 AM | Permalink | Comments (1)

I just recently discovered that HostedQA usage is picking up: now Apache MyFaces is using it too!

I'm personally really excited about this because it is one of the first cases where an opensource project has integrated with our products without any help directly from me. Very cool!

Posted by Patrick Lightbody at 06:49 AM | Permalink | Comments (0)

As of a couple days ago, I added HTTPS support to Selenium RC. This is a major addition, as it has been pretty much the only large feature missing from Selenium products. The result is that you can now remotely drive web browsers on sites that use HTTP or HTTPS protocols. Just as Selenium Remote Control was, this code was originally created as part of our HostedQA product.

Using this feature

To get started with testing on HTTPS, you have to use the custom browser launcher for now (we'll add support for it for the specific browser launchers as time goes on). The reason for this is that you need to import a Certificate Authority in to the main browser profile. Look in the advanced/security settings in Firefox/IE for this option.

You can find the CA at http://dangerous-certificate-authority.openqa.org/

Once you have the CA imported to the browser and have changed your tests to use the custom browser launcher, you can begin testing against HTTPS. Everything should just work.

How it works

Unlike other similar web testing tools, this solution doesn't require you to prepare the web browser for each domain you want to test. Rather, you only need to prepare the browser once by importing the CA.

What happens behind the schenes is that as each HTTPS connection is opened to a unique server/host combination, a mini-instance of Jetty is spawned off and used to tunnel SSL connections to the server. However, that Jetty instance needs a keystore that is signed by a trusted CA and is associated with the domain in question.

That keystore could be generated through a series of keytool and openssl commands, but we didn't want you to have to install these locally, since that can be a pain, especially for openssl. So instead, we created a web service at the dangerous-certificate-authority.openqa.org domain that generates the keystore for you.

The downside to this approach is that you must be online for HTTPS support to work. In the future we may offer a fallback that issues the keytool/openssl commands if the online service can't be accessed.

Give it a shot

The latest SNAPSHOT builds at maven.openqa.org should have SSL support available. Give it a shot, or wait for Selenium RC 0.8.2 to come out.

Or, alternative, sign up for HostedQA and start using these features (plus a ton more) today.

Posted by Patrick Lightbody at 05:20 AM | Permalink | Comments (0)

Selenium 0.8 Released:

Version 0.8 of the web application functional testing tool Selenium has been released.

Jeff Xiong explaing the new features...

(Via Ajaxian Blog.)

I'm especially excited about this release because of the implications with our HostedQA and AutoQ products. The reason is because I started the initial work on the multiWindow mode (though, admittedly, the rest of the Selenium dev team was absolutely required to make it finally work properly) for the very purpose of providing a frameless testing infrastructure for HostedQA.

We've actually been using this multiWindow/frameless mode in our products for a while in our products. The result is that instead of seeing your application inside of an iframe, your app runs in its own window, more accurately reflecting the real world usage.

You can see some example screenshots of what it looks like by checking out some of our opensource projects reports.

Posted by Patrick Lightbody at 06:47 AM | Permalink | Comments (0)