Hacker News new | ask | show | jobs
by andrewdavey 5519 days ago
I see a big problems in web testing caused trying to test drive from outside of the browser. I'm currently working on a solution that has tests written in javascript that run inside the browser. The test runner puts your web app into an iframe, so the test code can use jQuery, for example, to easily automate and assert over the UI.

JavaScript also makes creating a very clean testing-focused DSL easy.

I'm hoping to open source the project soon. If anyone would like to know more give me a shout (@andrewdavey).

1 comments

This is the approach that Selenium 1 took, and there be many dragons down that path. It's workable (we've done a ton of cool stuff at Sauce Labs making it work), but it takes an usual mix of skills and insight to get it to really gel together. Selenium 2 was built with all that mind.

That said, it's not the important part. Selenium (and watir, windmill, etc.) is an execution tool, it doesn't help you avoid some very, very large pitfalls waiting for you down the road. Too often your tests are tightly coupled with the dom, data and selectors are strewn all about, you have manual pauses and timeouts set by someone who left years ago, and you have so many that the whole thing takes two weeks to run (yes, I've seen this a number of times).

Basically, I don't care about the tool to execute the tests anymore. They'll all become interchangeable with Selenium 2 anyway. The much more valuable piece here is in creating tests that are maintainable and a joy to work with.

Certainly best of luck, please be sure to share you experiences and insights! There's always more to be learned.

Reducing tight coupling is definitely a concern I'm looking into. I can't see there being any silver bullets, but a good framework should certainly encourage a sustainable way of working.

I've developed a rather nice asynchronous, sequential, execution model for test code. So they avoid the callback-hell you'd see with multi-step async tests. The spin assert idea mentioned in the article is very useful, and I'll be borrowing it for sure! :)

I'm wary of running tests in parallel, due to concurrency issues. However, I guess spinning up multiple web servers and in-memory databases would work fine.