Archive for March, 2010

Watij WebSpec is born!!

Tuesday, March 30th, 2010

This post has been a long time coming. Brian and I started Watij a bit over 5years ago and from the start we envisioned a lightweight application testing framework written in java that would allow folks to automate their web applications. We have learned a ton and since have written other frameworks and continued in our quest for making testing easier.

After partnering with TeamDev, Watij became an opensource project built on top of a commercial product. It was great news for us and for Watij. At some point (maybe two years ago) we heard about a new product that TeamDev was planning….JxBrowser. The initial idea was that it would be a similar component to what we were using for ie support. TeamDev changed directions and boy was it a great opportunity for us to grow our relationship with them. JxBrowser was to become a multiplatform multibrowser swing component. We quickly saw the potential for Watij and began to discuss what it would mean for Watij to be multibrowser capable…..we felt change was needed.

We saw some problems with our existing approach. Unfortunately we were abstract happy…we had too many interfaces and too much inheritance that made following the Watij code a bit cumbersome. I will say that it was very modular and was written well…I just think it was “too much abstraction”. We abstracted before we had a need. We didnt have multibrower support, but were coding as if we had. We also noticed that ie specific code began to creep into watij core. So we wanted to rethink everything…. Based on our learnings over the past 5 years we wanted to make Watij lighter, faster, leaner, and meaner.

Yes that is scary…scary for you and us as well. We are taking a small gamble here and have completely rewritten Watij and are reintroducing it as WebSpec. This has some very large implications for you. The next version of Watij is NOT backwards compatible. If you know me you know that I subscribe to the belief that you should never see Watij code in a test case. You should a dsl for your application where the dsl implementation uses Watij. If you followed this pattern, you will change your dsls implementation and be done. If you have not taken that approach and your test cases are tightly coupled to the current Watij api…you have some work to do!

We have dropped the implementations of every html element as concrete classes and have opted for a much smaller api built around accessing and manipulating webpages using javascript. In a nutshell, when you make calls in watij, they will be proxied through to the JxBrowser component. This gives us immediate support for Safari, even though DOM is not supported for Safari on JxBrowser. We have also taken the approach of providing a more fluent interface for using watij.

What happens now??? Well, that is a great question. We would first like to get some feedback. So checkout trunk and take a look at the watix directory. There is a run.sh that will kick off a sample test. Of course we will need to create new documetation, usage guides, the whole nine.

So thats it for now…I’m sure in the coming days/weeks we will have some healthy debate over WebSpec.. :)

Happy Testing!