The First Selenium Camp in Europe

I was lucky to visit the first Selenium Camp in Europe last Saturday. It was held in Kiev by XP Injection group.

Even though I am not a QA-or automation testing engineer it was quite useful to visit it. The first reason is we do use (or trying to use) Selenium for functional testing in our project, the second one it is quite nice to feel myself in the shoes of guys how test software all the time. As for my real experience it is quite small, I was just using IDE and RC to create some simple tests and even before I was using WatiN for some functional testing. But Selenium is a real bomb... just imagine, it becomes so popular that people organize big conferences about it!

Let's start from the basics, your Captain speaking:

Selenium is a portable software testing framework for web applications. Selenium provides a record/playback tool for authoring tests without learning a test scripting language. Selenium provides a test domain specific language (DSL) to write tests in a number of popular programming languages. Test playback is possible in most modern web browsers. Selenium deploys on Windows, Linux, and Macintosh platforms. 

Selenium contains several parts:

1. Core written in pure JavaScript, 

2. IDE as a Firefox extension that allows to record, edit, and debug tests, 

3. Remote Control (RC) that allows you to write automated web application UI tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser, 

4. Grid  allows to run tests on many servers at the same time, cutting down on the time it takes to test multiple browsers or operating systems.

5. Many extensions, integrations etc.

The kick-off meeting I visited was David Burns's "Selenium 2 : The future of Selenium is now!". As a result of a presentation I found that future of the Selenium is quite solid, many good thing like web drivers, fluent and simple API, caching elements collection are provided.

Web driver is a layer between Selenium Core and browser engines, created specially for each supported browser, that means written within the native environment for it, C++/COM for IE, extension mechanisms for FF and Chrome, etc. On the other hand web driver is ready to be used within high level languages like C#. Sometimes it is better to use WebDriver than Selenium and vice-versa. But just look at that:

[TestFixture]
public class GoogleIETest
{
  IWebDriver driver;
      
  [SetUp]
  public void Setup()
  {
    driver = new InternetExplorerDriver();
  }
     
  [TearDown]
  public void Teardown()
  {
    driver.Quit();
  }
      
  [Test]
  public void TestSearchGoogleForTheAutomatedTester()
  {
    //Navigate to the site
    driver.Navigate().GoToUrl("http://www.google.ua");

    //Find the Element and create an object so we can use it
    IWebElement queryBox = driver.FindElement(By.Name("q"));

    //Work with the Element that's on the page
    queryBox.SendKeys("The Automated Tester");
    queryBox.SendKeys(Keys.ArrowDown);
    queryBox.Submit();

    //Check that the Title is what we are expecting
    Assert.True(driver.Title.IndexOf("The Automated Tester") > -1);
  }
}

Yes, It looks just like in WatiN, but it is only a simple example, Selenium provides us with lots of advanced features. What about to be integrated with behavior driver development, run tests in concurrent mode for the different environments, file upload... Selenium is about that. But something is not so brilliant with new Selenium, i.e. Grid 2 future is not so clear. There is no support for Silverlight.

The second and third presentations I visited were about sharing some experience of using Selenium. Kirill Klimov and Mairbek Hadikov had shown us their way of progressing with Selenium from IDE to Grid. Kirill  described us the pros and cons of each Selenium tool form Core to Grid. As for me, I enjoyed RC the most. Mairbek had presented us some valuable advices:

1. Use automation testing

2. Integrate automation tests to Continuous Integration server and run test frequently.

3. Use code review for the test code

4. Use Selenium 2 :-)

5. Use CSS selectors, they are faster and more reliable that x-path

6. Use BDD or write test code that is clear to nontechnical people

7. Isolate test from the environment

8. Try to avoid side effects

9. Make assertions after selectors

10. Think about concurrent testing, different environment ...  thing about Grid

Of course, these advises are simple and common but some of them are regularly forgotten while writing tests.

The following topics I visited were devoted to integration of development process and Selenium.

For example, Aleksey Rezchikov shared his experience of using Selenium within Agile-oriented development. Some moments were quite interesting, i.e. there is a bunch of tools to bind a user story and functional test to make a story test: FitNesse,  Concordion, Cucumber, etc. Also he mentioned quite strong reasons to use PageObject and Feature Flags patterns.

One of the major Camp organizer Nikolay Alimenkov have shown as his way of creating acceptance tests using Selenium + Wiki = Live Requirements. This approach seems to be very cool but I am not sure I will be able to force my Product Owner to write acceptance tests even using wiki :-).

I was not sure that Selenium is able to handle rich Ajax application before the camp, but Sergey Shvets had shown his way of testing such things, and recipe was quite simple: use pauses, jQuery, atomic blocks of testing to manage Ajax requests: post backs. counts etc.

The presentations from Selenium Camp are here.

Remember, if developer is also a tester he is a Product Developer! :-)