One major problem for me with building web applications has always been testing the presentation layer of such an application, that is, the part rendered in the web browser. This not only includes ensuring that when a user submits information or clicks on links on a page the expected behavior happens, but that it happens in all the popular browsers. Making the assumption that because it runs in one browser means it will run in all is one that has been thrown to the wind a long time ago. The quirky behaviors made famous by Internet Explorer and poor CSS implementation have assured us of that. Despite open standards and open specifications, somehow consistent browser behavior still remains a mystical holy grail for web developers and users alike.
These days the browser suite has grown to include not only IE and Firefox on the desktop, but Opera, Safari (for Mac and Windows) as well as the recently released Google Chrome. Added to this are the new market of browsers for mobile devices such as 3G phones and wi-fi enabled PDAs. Even game consoles such as the PS3 and Nintendo Wii have web browsing capabilities, and all of these behaviors may need to be tested depending on the market a web application targets.
Selenium is a suite of tools to automate web application testing across many platforms. A great introduction to the tool suite and its capabilities already exists on its website. This post is about one of its features that is of particular attraction to me as a professional .NET developer, that is the ability to generate C# code from a test recorded in Firefox using the Selenium IDE plugin.
Utilising Selenium Remote Control and running the Selenium server included in this the generated test code can then be integrated into a .NET project and run from within Visual Studio. This would seem simple, and in fact the online demo is correct in how simply it is to generate testing code, however once you move to the Visual Studio IDE issues can arise.
One major pitfall I hit was once I had written my tests and clicked the "Run Test" button the security error "The location of the file or directory '...\bin\debug\ThoughtWorks.Selenium.Core.dll' is not trusted." would pop up and prevent the test from running.
It took some researching, but it was finally explained by this MSDN post.
Firstly, to implement the .NET code generated for tests your .NET project will need to reference the ThoughtWorks.Selenium.Core.dll included in Selenium Remote Control zip file. When I unzipped the folder I placed it on my Windows desktop. This DLL is included in the folder contents precompiled and so was unzipped into the desktop folder as well, and together that created the issue.
In Windows Vista (at least, not sure about Windows XP), when you attempt to use a .DLL file that was not compiled locally but acquired from the Internet or other location, Vista marks the file as potentially unsafe once it is copied to your local machine anywhere under the "Users" folder (which includes the Desktop, Downloads and Documents folders) and prevents it from being executable. One must first right-click on the file from Windows Explorer, go to Properties and click "Unblock" in order for the file to be marked safe for execution from within the Visual Studio debugger.
The workaround to these types of issues (referencing precompiled DLLs) I've found has been to unzip such folders directly to the root of a drive (C: for instance), and the referencing of such DLLs does not produce the same issue since apparently the automatic blocking happens only to files placed inside the "Users" folder.
Hopefully this post will save new Selenium users some time and not discourage the initial excitement about such a powerful, yet simple to use, tool. As I continue using it hopefully I'll have some more tips and experiences to share.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment