Google's Chrome web browser was released in September of 2008, and is an increasingly popular browser to use for testing using Selenium. The RC was patched on the day that the web browser was released with a new browser launcher for Chrome. You'll need revision 2408 or later. There is nothing special that one must do to start a Selenium session using Chrome. All you need to do is call the Selenium constructor with the browser type argument of "*googlechrome".
For example:
from selenium import selenium
s = selenium("localhost", "4444", "*googlechrome", "http://www.google.com")
s.start()
Current Bugs:
Wednesday, February 11, 2009
Monday, October 20, 2008
First Resort Approaches to Testing a Web Application
Testing a web application is not simply a task of making large selenium integration tests. In fact, this should be the last thing that you do after getting all of the individual pieces tested. There are many pieces that go together with completing a test effort for the app. Creating a variety of small tests can make life a lot easier and can expose bugs during development, early in the life cycle of feature development.
The following are some areas that you don't want to miss when testing your application:
One of the first things to do is unit test your Java code. This is easy for the developers of the features to do as they write methods and classes and check them in. Unit tests should be set up in a continuous build to expose bugs quickly.
Today's web apps include a lot of javascript for dynamic features, and sometimes these pieces can comprise a lot of the code that contributes to the feature set of an application. So, the second most important part of your testing package is to develop JS unit tests for all the classes and method delivered to the browser.
How do you run these tests. Selenium can be easily used to load javascript tests and run them. The key holes into the the javascript here are the getEval function and the runScript function. In fact, one could develop an entire framework for running JS tests automatically. Still, using Selenium requires opening up a browser, which takes a relatively long time. An interesting idea here would be to to develop a service that could extract the javascript interpreter from the rendering engine. You could send javascript the service with you JS unit tests to adequately test all your javascript.
The final page rendering is also quite important, because this is what the user sees and what he interacts with. It's a true test of the user experience. Having a set of pages that a heavy user of the web application might expect to see should be the goal here. You can do all of the set up work for these pages using API's or the javascript service and then you can use Selenium to navigate to the expected resulting page. Selenium can be used to test elements on that page, or an image comparison tool can also be used to test that the page looks as expected to the user.
Finally, the old fashioned way of Selenium is necessary for a complete integration and sanity check of the entire system. Basic functionality should be tested to ensure quality. Remember that limiting the number of large tests for a web application is important for reducing maintenance costs, and for ensuring that the most important pieces of the app are tested.
The following are some areas that you don't want to miss when testing your application:
One of the first things to do is unit test your Java code. This is easy for the developers of the features to do as they write methods and classes and check them in. Unit tests should be set up in a continuous build to expose bugs quickly.
Today's web apps include a lot of javascript for dynamic features, and sometimes these pieces can comprise a lot of the code that contributes to the feature set of an application. So, the second most important part of your testing package is to develop JS unit tests for all the classes and method delivered to the browser.
How do you run these tests. Selenium can be easily used to load javascript tests and run them. The key holes into the the javascript here are the getEval function and the runScript function. In fact, one could develop an entire framework for running JS tests automatically. Still, using Selenium requires opening up a browser, which takes a relatively long time. An interesting idea here would be to to develop a service that could extract the javascript interpreter from the rendering engine. You could send javascript the service with you JS unit tests to adequately test all your javascript.
The final page rendering is also quite important, because this is what the user sees and what he interacts with. It's a true test of the user experience. Having a set of pages that a heavy user of the web application might expect to see should be the goal here. You can do all of the set up work for these pages using API's or the javascript service and then you can use Selenium to navigate to the expected resulting page. Selenium can be used to test elements on that page, or an image comparison tool can also be used to test that the page looks as expected to the user.
Finally, the old fashioned way of Selenium is necessary for a complete integration and sanity check of the entire system. Basic functionality should be tested to ensure quality. Remember that limiting the number of large tests for a web application is important for reducing maintenance costs, and for ensuring that the most important pieces of the app are tested.
Sunday, September 7, 2008
Why a Selenium Farmer
For my first blog post, I figured that I should talk a little bit about myself and what it means to be a Selenium Farmer at Google. I first got introduced to Selenium because some people I knew embraced this tool as the golden goose for testing web applications. Selenium could be the powerful tool we needed to use to create large scale integration tests and automate the manual tester out of the picture. Selenium's ability to automate the web browser was unparalleled and extremely powerful. It took the place of a user and could do anything that a manual tester could do at a larger scale, a lot faster, more reliably, and for a lot less money to a company. It was a thrilling technology and investment in it was made.
In practice, Selenium isn't the perfect tool for all testing. It leaves a bit to be desired in some of its abilities and functionalities, however it carries great potential and as an open source project, it is thrilling that anyone can be a part of contributing to the effort. At first an end user of the Selenium Remote Control, I was able to see some of the things that Selenium lacked, and I wanted to make myself a part of making the tool better. I wanted to be at the head of the effort to make it the chosen option for large tests for web applications. So, I made my debut as an open source community developer by contributing to this project.
I have a unique opportunity to see some of the issues that people have while using Selenium because I am a software engineer at Google. I get the chance to interact with Selenium test developers in a large and tightly knit community. Google's web applications are at the cutting edge of browser capability and test engineers there are at the cutting edge of testing these products. Consequently, Selenium, as one of the many testing tools used for exercising web products, is constantly being pushed to its limits. I get to see what works well and what doesn't from a first hand perspective, and I get to work on fixing these issues for my community and for others. I have a unique view into Google's Selenium Farm, which was the first major effort to do wide spread Selenium test distribution.
With this knowledge, I am writing this blog to share my experiences and my thoughts for the industry.
In practice, Selenium isn't the perfect tool for all testing. It leaves a bit to be desired in some of its abilities and functionalities, however it carries great potential and as an open source project, it is thrilling that anyone can be a part of contributing to the effort. At first an end user of the Selenium Remote Control, I was able to see some of the things that Selenium lacked, and I wanted to make myself a part of making the tool better. I wanted to be at the head of the effort to make it the chosen option for large tests for web applications. So, I made my debut as an open source community developer by contributing to this project.
I have a unique opportunity to see some of the issues that people have while using Selenium because I am a software engineer at Google. I get the chance to interact with Selenium test developers in a large and tightly knit community. Google's web applications are at the cutting edge of browser capability and test engineers there are at the cutting edge of testing these products. Consequently, Selenium, as one of the many testing tools used for exercising web products, is constantly being pushed to its limits. I get to see what works well and what doesn't from a first hand perspective, and I get to work on fixing these issues for my community and for others. I have a unique view into Google's Selenium Farm, which was the first major effort to do wide spread Selenium test distribution.
With this knowledge, I am writing this blog to share my experiences and my thoughts for the industry.
Subscribe to:
Posts (Atom)