In an earlier post, I provided step-by-step instructions in how to perform Behavior Driven Development using Visual Studio, SpecFlow, WatiN and DryRunner. However, I’ve had a lot of students and blog readers ask me about Selenium, a more-common browser automation tool. So, I’m writing this post to show how to accomplish BDD and automated test driven development (ATDD) using Selenium.
What is Selenium?
Taken from its website, “Selenium automates browsers… it is for automating web applications for testing purposes…” Selenium comes in two flavors – a WebDriver and IDE. Again from its website, the webdriver is for creating robust, browser-based regression automation suites and tests along with scaling and distributing scripts across many platforms. The IDE is for creating quick bug reproduction scripts and creating scripts to aid in automation-aided exploratory testing.
The IDE is a plugin that installs into the browser allowing you to record interactions with a website as XML scripts. Then, you, someone else or an application can automatically execute these scripts from within the browser. This reminds me of a product called DéjàClick by AlertSite. (I once worked for AlertSite before it was bought by SmartBear.) DéjàClick is a browser automation tool for either Firefox or Chrome (they once supported IE, but not anymore), but is primarily used for load testing. DéjàClick, like Selenium’s IDE, records user interactions with a website, then the user can upload the recorded script to AlertSite. AlertSite’s servers, in return, can simulate user interaction with a site testing the site’s performance under specific loads. Selenium, on the other hand, simply allows a user to “replay” interactions in order to perform regression testing on a site.
Much like WatiN, Selenium’s WebDriver allows a developer to use code to interact with a browser. Via code, a user can navigate to pages, complete forms, execute embedded scripts and locate elements on a page. For behavior driven development using Visual Studio with SpecFlow, the WebDriver is the flavor of Selenium that we would utilize.
Selenium vs. WatiN
Which should I use? Which is “better?” Well, the answer really depends on your and the application under test. The following are some considerations for determining which tool to use for automation testing.
Ease of Use
First, what is your comfort level with BDD? If you are a beginner and just learning BDD, I would recommend WatiN. You’ll notice that my tutorial used WatiN. I believe that WatiN is a little easier while one is overcoming the learning curve of BDD. I don’t necessarily believe that BDD is difficult, but I do believe in minimizing variables in order to lower the learning curve. Therefore, while one is in the process of learning and becoming comfortable with BDD, WatiN will take less time to implement. Selenium has a lot more features and capabilities than WatiN; and, as always, with an increase in features comes and increase in learning requirements.
To reiterate, Selenium, by far, has more features than WatiN. (Some of those are listed in the following paragraphs.) Selenium is a much larger project, supported by more developers whereas WatiN is supported by a single developer. Selenium can execute interactions against the browser via code or XML. Selenium can also perform XML queries against the page using XPATH in order to locate elements.
I also found that, due to its age, WatiN does not support HTML5 elements (i.e. <input type=”number” /> for example). In order to test the textbox using WatiN, I had to change the textbox type to “text” which, in my opinion, can defeat the purpose and is bad design. I never want my application to change in order to support a testing framework. Instead, it’s the other way around – my testing framework should support my application. Selenium uses a generic IWebElement to capture page elements. Compared to WatiN that only allowed me to “type” text into an object of type TextField, Selenium uses a different approach. Selenium allows me to “SendKeys” to any IWebElement, whether it accepts a character or not. This generic implementation, gives me greater control of my page interaction.
WatiN only supports IE and Firefox natively. Selenium, on the other hand, supports browsers through an IWebDriver interface. By implementing this interface, developers are able to contribute to the Selenium project with support for many browsers. At the time of writing this blog post, Selenium supports multiple browsers including, but not limited to Internet Explorer, Chrome, Firefox, and Safari. There’s even support for mobile browsers.
As I just stated, WatiN only supports IE and Firefox. It does this through native Windows COM, which makes more a slightly slower mechanism. Selenium’s interaction, again, is handled by specific IWebDriver implementations that create small “servers.” These servers must be downloaded for each browser you wish to test against. Additionally, the servers must be either added to your system PATH environment variable or dropped in your acceptance tests BIN folder.
One other thing I might add is that I had some issues with getting the InternetExplorerDriver working my development environment, which is Windows Server 2012, due to intrinsic permissions. In order to get the IE driver to work, I was required to update some security settings in IE and reboot the OS. For the other browsers, simply dropping their respective drivers in my acceptance tests’ BIN folder was sufficient.
WatiN has been around for a while, but it is maintained by a single developer. Additionally, looking at the last update date on Sourceforge, WatiN has not been updated since September, 2012. Selenium is maintained by a team of developers and is under continual development. Selenium also has quite a large public following allowing anyone to contribute to the project. This is, I believe, is another reason why Selenium has many more features.
There’s really no huge difference in coding the basic page interactions. I updated the Calculator project code to use Selenium instead of WatiN in literally, less than 15 minutes. But, as I’ve already stated, the Calculator project is only a demo of BDD and Selenium is much more powerful than WatiN.
If you’re getting started with BDD, WatiN is a good starting point as there’s less of a learning curve. If you are comfortable with BDD and are ready for a (very) slightly higher learning curve, I would encourage you to try Selenium as it gives you more features like greater support for browsers and new HTML5 elements.
Updating the Project
There really were very little changes needed to transition my project from using WatiN to Selenium. As I mentioned above, it took me less than 15 minutes to do so. The major difference is the Nuget packages required. In order to use Selenium for your automation tests, you’ll need to install and reference two separate Nuget packages/libraries whereas Watin only required one:
You can download the Selenium version of the Visual Studio 2013 project here.