After finally fixing SmallHttpUnitTest for VisualWorks and having talks with several folks at Smalltalk Solutions, I felt it was time to revamp SmallHttpUnitTest. For one, it was slightly misnamed in that the tests are really end-to-end acceptance tests. I was trying to make the navigation easier through the objects. But, somewhere I made a wrong turn. I started to really look at the Selenium Testing Framework. It runs your tests in the browser via Javascript. Nice. It's simple and it works with a nice a table structure like FIT. You can even command it remotely from another language as well such as Smalltalk, java, Ruby, and more.
Well, it all got me thinking how nice it would be to drive the browser like Selenium does, but with the nice object traversal that I used for SmallHttpUnitTest. You can command Internet Explorer, Firefox, and Opera via Javascript. It's a slightly different idea from Selenium in that the web page that you're loading does not need to have any Javascript loaded. The Javascript works externally via a script that runs the web browser via COM (for Microsoft) and I'm still researching Firefox/Mozilla (but, I know its possible to drive them with Javascript as well). It would seem some Ruby people had the same idea! But, I want to take it further. Javascript makes a lot of things easy since it is so well-integrated into the browser.
The pieces of SmallHttpUnitTest that are in Smalltalk will be re-implemented in Javascript. A lot of the browser handling code is no longer needed! The Smalltalk piece will be an external application that watches what you do as you're traversing your web application and takes notes. Once you've finished navigating, you could update your asserts for each page load and have Smalltalk generate the Javascript for you. I'm doing the proof of concept for Internet Explorer since I am more familiar with the OLE/COM model to drive IE. But, I expect Firefox to be a no brainer. I should only have to replace one object and everything will just work. So, you could have one script that drives both. There's a few more surprises that I want to work out and I will be blogging about them. I have a lot of work ahead of me. This a completely different approach than what I was thinking of doing at Smalltalk Solutions. I've been slow doing the prototype, but I have been a busy boy!
You might be wondering how I got the DOM searching of HttpUnitTest working in Javascript since it uses generators and doesNotUnderstand: a lot. Well, that's a topic for another blog entry. Let's just say that higher order functions are your best friend.
Subscribe to:
Post Comments (Atom)
Posts
3 comments:
Why go down the whole COM route, instead of the in-browser javascript model that selenium uses? We're doing a COM approach in work, and it's nasty. We're looking at selenium with envy.
Really COM is a small piece. In fact, it's just the driver to get an instance of IE. I don't plan to use COM for Firefox. It's just for the reference implementation. The interesting bits will be in walking your DOM model and more intention revealing tests. Also, the more fun bit will be generating tests. I want to stick to standard Javascript as much as possible. In fact, I'm hiding all of the COM stuff behind an object and so far, it's very little of the code. I will be using more Javascript in the browser, but it will not be in the page.
Blaine, you should talk to your friend Mark P. He implemented a COM based HTTP testing framework in VAST. Like you, he simply used the COM interface as a browser driver. It's hidden inside an object and he's talked about plugging it into Firefox.
Post a Comment