Wednesday, June 27, 2007

6 things wrong with iPhone

Now that journalists are falling over themselves to praise the new iPhone from Apple. Its time to debunk the hype. Here's 6 things wrong with the iPhone.

6) Touch-screen keyboard sucks. A good slide-out keyboard is much better idea like the new models from Helio or Samsung.

5) No apps download, so no crappy J2ME games. But realy what was Apple thinking? On a crappy 2.5G network connecting to Internet is crapshoot at best. Now they want you to use applications online?

4) The camera is circa 2006: 2 megapixels and no iFlash.

3) Only works with iTunes and no memory card slot. Here Apple is still ahead of Nokia because they insist on using RealPlayer. But how does experience compare to dedicated music phones like Sony Ericsson's walkman phone?

2) Surfing with anything less than 3.5G nowadays is literally a waste of time. I havent seen't the browser but I tried the latest browsers from Opera and Nokia with the same capabilities.

1) Actually makes it harder to pick up the phone and call someone.

disclaimer: I never tried the iPhone, so this is all hearsay.

Sunday, June 10, 2007

More on using Selenium and Rails

After attending the Silicon Valley Ruby Conference and seeing the Selenium, the open-source web-testing framework in action, I decided to give it a try. Selenium makes it easy to write test scripts using a macro language done in pure javascript. Here's a sample script in "Selenese" that performs a login action.


If you ignore the '|' which is a separator, its just plain english. If you don't want to manually type in Selenese, you can download Selenium IDE, a macro recorder that converts your actions into test scripts. You can also take a look at this excellent screencast.

So far so good, you can automate tests in just 2 steps: 1) Use macro recorder to record a script 2) run the script as a test. But you still need to verify the results of your tests. Selenium can parse the contents of a webpage using regular expressions or XPATH. Eg. to verify that the login test passed, you can search for the phrase "Welcome, XXXXXX".

The real question is whether Selenium can test all aspects of your website. The answer is yes, but you probably don't want to do it that way. Selenium is a pure javascript framework so there are somethings it cannot do. It cannot fill in the upload box of a javascript form because of security restrictions. It cannot access state variables such as the session or the database because it runs only in your browser. See my last post on Pivotal Labs: they have created a Rails plugin which runs Selenium in a separate process and allows full access to Rails framework. But it is necessary? I don't think so -- at least not for me.

Lets not forget, Selenium is designed to run inside the browser so it can test the user experience. You want to verify that the user's actions produce the correct results in the browser and not just in the database. All this requires a little bit of creativity and some javascript. Take the case where the user registers and receives an email with confirmation code. Selenium can fill out the user registration form but can't see the email. So I add a test-only method that will render the email message as a HTML page.

Test Script
1) User registers as "bob@yahoo.copm"
2) Call test method to render email message for ""
3) Use javascript to extract registration code of "XXXXX"
4) Goto page /user/confirm?code=XXXXX
5) Verify user is shown his new profile page

The entire test takes place inside the browser. The best part is there is no need to run Selenium in a separate process. Executing the test is very simple (checkout Selenium on Rails), open testrunner in your browser and run your test suite. I have been able to do all of testing using a simple setup. There are scenarios that are difficult to test, eg. uploading files as I mentioned earlier. But some of that you can do inside functional or unit tests. Overall, I have found Selenium to be an indepensible piece of the testing suite, precisely because it tests what matters to your end-users, what they see in their browser.