The video is an automated recording via Saucelabs. Selenium RC / Soda allow you to automate acceptance testing, paired up with Saucelabs allows you to do so across a matrix of operating systems, browsers, and browser versions completely automated using the Soda client (along with the selenium IDE if you choose) to write your tests.
While all the work to bring things to Javascript is nice I'm not sure that everything needs to be wrapped in Javascript. I guess someone could argue that people who do web design know Javascript so this would let them create tests easier but do most people write these tests by hand or use IDEs to record them?
What's the harm in having tools written in Javascript? Now that it's getting used on the server more often, it's nice to be able to use the same language everywhere.
Stating from experience. The IDEs tend to be inaccurate. They can provide a good skeleton for a test suite. But they have a hard time recording interatction with modals, animations, or facebook connect elements. Using an IDE you will find yourself returning to the generated code and hand coding other interactions.
I know it's not exactly the intended use, but does this allow one to effectively run a headless browser with JS from a server with Node installed? (Right now I'm generating server-side snapshots of Raphael.JS drawings with wkhtmltoimage, but I'd much rather get the actual SVG and run it through Inkscape.)
When you run a browser test on a cloud service, how do you know if it looked good or not? We created the video recording part of Sauce's testing service so you can see how the browser test worked in our cloud.
The test makes sure that provided invalid credentials (user and password), the message "please check your username and password" will show after making an ajax call to the server.
Headless browsers are faster, but they're not a real browser. Selenium was explicitly created to answer the question: "How does my app work in the actual browsers my users use?"