UI Automation With C# and Selenium: Adding Packages

The Takeaway: Installing the right packages from the start makes everything else a lost easier.

So far, we’ve created a blank solution with a few projects and added that solution to a repository. Now we need to install the right packages so that when we start coding some tests, everything will be in place and we won’t need to go back and figure out what we’re missing. For our automation, we’ll start out with the following packages:

  • Selenium
  • NUnit
  1. In your automation solution (which you can find the previous post for here), Navigate to Tools > NuGet Package Manager > Manage NuGet Packages for Solution

    Visual Studio - Manage NuGet Packages
    Visual Studio – Manage NuGet Packages
  2. Select the Browse option and search for Selenium 

    Visual Studio - Selenium NuGet Packages
    Visual Studio – Selenium NuGet Packages
  3. For each package Selenium. WebDriver and Selenium.Support, select the package. Notice that the project where our tests live is the only option available installing this package. Remember, since the framework is a Shared Project, there’s no DLL file created for that project, but the files required for the tests will be automatically included when the test project is built 

    Visual Studio - Packages Install in the Test Project
    Visual Studio – Packages Install in the Test Project
  4. Select the Test project (UI Tests in the example above) and select the Install Button 

    Visual Studio - Installing Packages
    Visual Studio – Installing Packages
  5. You’ll probably need to confirm the install of each package as well 

    Visual Studio - Review Package Install
    Visual Studio – Review Package Install
  6. After both the Selenium.WebDriver and Selenium.Support packages are installed, search for and install the NUnit and NUnit .Console packages as well 
    Visual Studio - Installing Nunit Packages
    Visual Studio – Installing NUnit Packages

    Once the NUnit packages are installed, you can select the Installed link and see that several NUnitpackagaes were installed. These packages will be the basis for our framework and tests, but we’ll add more as we progress.

In Defense of Open-Source

Over the past few months, I have seen some criticism of open-source software testing tools. Joe Colantonio, for example, recently interviewed a guest for his podcast (I cannot remember whom) whose summation of open-source testing tools was (and I’m paraphrasing): Why use an open-source tool when you can purchase a product that does a majority of the set-up work for you?

Additionally, I’ve read several other rejections of open-source tools (like Selenium) for various other reasons: It’s more difficult for unskilled workers to use, there is less support for open-source tools, and there’s always a possibility of closing the source, making it a paid application, or, even worse, stopping the development of the tool altogether.

I will suggest that open-source tools are not only great tools to use but are essential to the continuation of the development of the QA role in software development.

Open-source is not “free”. We know that already. The primary costs, it seems for open-source testing tools are:

  • The time it takes users to become familiar with the software
It takes time to learn to use a new tool when a choice is adopted. However, this is also true of paid applications as well. QA and development tools ALL take time to learn how to use correctly. Jira, QTP, QAComplete, even SharePoint all have learning curves, regardless if they are open- or closed-source.
  • The time it takes to develop the tool

One primary advantage paid applications say they offer over open-source tools is that so many of the features are already developed, connected, and work out-of-the-box, as it were. This is probably true in most circumstances. For an enterprise to purchase a QA/testing tool, especially a complete testing tool, gets you up-and-running quickly. Open Source tools are not as connected, not as structured, and require more time on the front-end for use.

However, I also suggest this is one of the strengths of open-source. I am a big believer in DIY, and feel that certainly, a user can simply use tools to accomplish work, but a user that understands their tools, understands how they are constructed, knows the inner-workings of their applications, and knows how and why elements are connected like they are, will have more success in the long term. For users that do not understand their tools, any defect in the tool, any diversion from the expected course, or any change in features, is potentially the death knell of the use of the tool. It’s akin to seeing the check engine light on your car and automatically assuming the car is undrivable. There may be a major issue with your car, certainly, but it could just be that the gas cap isn’t secured tight enough. An understanding of your tools allows a user to understand problems when they arise and usually makes for a more complete and confident user as well.

Think about this: If you plan to spend money on a testing tool, would you rather put that money towards the purchase and maintenance of a tool, or toward the salary of a user that can accomplish the required tasks using open-source tools? My money goes to paying trained users that understand the process, understand the tools, and can put the tools to their best use. Invest your money in people, not things.

The argument that open-source tools may be shuttered at any time is also not a very strong argument. The true nature of open-source is collaboration between many individuals. True, using an open-source tool developed by one or two people has the possibility of being abandoned at any time, but the very nature of open-source projects is collaborative. Last time I saw, Selenium Builder has 30 contributors on GitHub (of varying degrees of contribution, of course). Obviously, take care in choosing your open-source tools. Apache isn’t going anywhere anytime soon, right?

Lastly, I would suggest that the future of the QA community lies in the use and development of open-source software. The development of “development”, if you will, includes many attempts at open-source software with contributions from millions of developers, and has resulted in many open-source tools that have become standard technologies: Linux, Apache, MySQL, and PHP, just to name a few. The future of QA is becoming more technical, with the increasing interest in automation and the frameworks that are required in order to successfully conduct an automated testing project. We are only in the beginning stages of this technical revolution, and as open-source QA tools expand, so will the influence and importance of quality assurance in the process of delivering quality software to customers.