Selenium 2 is one of the most anticipated updates to a testing framework in a very long time. The next version of Selenium will see the Selenium and WebDriver code bases merged. It will allow developers to be able to switch between Selenium and WebDriver without having to change your tests.
"So what" you might be thinking? Well, Selenium and WebDriver have their strengths and in a number of places they are in opposite places. For Example, Selenium works on every browser that supports javascript where WebDriver requires a driver for each browser.
The merge, destined for use by Selenium Remote Control and WebDriver users, will allow developers to write developer centric tests tests in their favourite language. So how does it do this at the moment? The Selenium and WebDriver developers have created an uber-jar that houses both the WebDriver and Selenium API's. Developers create their tests as normal and call the same server for both Selenium and WebDriver.
I am sure that you are still going "So what?".
Ever had a situation where you tried to use the down arrow in your Selenium test to only start pulling your hair out! This means if you use the WebDriver backed Selenium, you will be able to get around any issues what Selenium Remote Control may get stuck on. E.g. The most common issue is when trying to do keypresses, Selenium will synthesize the keypress using JavaScript where WebDriver will send through keypresses at the OS level.
We will also be able to create more intuitive tests since WebDriver allows people to create objects in their tests for each object on the page by using WebElements like this : - WebElement elementOnPage = driver.FindElement(By.Name("idOnPage")) and then use it like with typing elementOnPage.SendKeys("Text")
The .NET Bindings have a lot of potential and Jim Evans and the rest of the Selenium-WebDriver Developers are doing a brilliant job! Keep up the work guys!
So to get some people going with the .NET bindings I have created some tutorials:
Monday 11 January 2010
Selenium 2 .NET Bindings And How We Can Use Them
Saturday 2 January 2010
Every time a child says, 'I don't believe in fairies,' there is a fairy somewhere that falls down dead.
Peter Pan is one of my favourite stories and the title of this post is one of the most iconic phrases to come out of the book.
It's at the beginning of the book when Wendy and Peter are speaking. Peter explains that when the first baby laughed, its laughter fell and broke into a thousand pieces. This big breakup of laughter means that there "ought to be one fairy for every boy and girl". Wendy notices that Peter said should and questions him.
"Ought to be? Isn't there?"
"Every time a child says, 'I don't believe in fairies,' there is a fairy somewhere that falls down dead." Peter replies.
The same can almost be said about testers when a developers don't check their code works. I don't mean a tester will die every time but a small part of their resolve dies everytime. If its not a testers resolve that dies, it may be real people that die. This may sound quite extreme but its not really.
Since the begiing of the Agile movement there has been a great movement to get the quality of software a lot higher. Aside from all the other major benefits of using scrum and XP, people have noticed the quality of software being delivered go up. They have done it by employing things that make the process more effective. Not all of these processes are efficient but they are extremely effective.
Testers resolve only dies when they feel that something could easily have been caught by the developers being effective at their job. Being efficient can lead to bugs because we are trying to develop a feature within a set timeframe which is normally slightly shorter than it should be. This is not all doom and gloom, there are bugs that testers love to find. Remember the rule for testing that if a test case is good it will find a bug but remember that testers are not there to make sure that you are doing your job properly. They are there to make sure that its fit for purpose!
When developing software always remember that you are killing your testers really slowly when you are not doing your job properly!
"To die will be an awfully big adventure." Peter Pan
This is something that every tester, from load tester to functional tester to security tester, loves to do. Make an application fall to it knees because it we managed to find some big hole. Making an application die is an adventure in many many ways. From going through the process of breaking it, to working out the cause of the breakage.
I have just watched Peter Pan for the umpteenth time and it got me thinking about my profession. Treat your testers like you would Peter Pan and they will be a lot more effective in finding those elusive bugs!
