Setting Up C#
In order to work with C#, you need some instance of the .NET platform available to you. You’ll probably also want some IDE although that is optional.
In most of my posts and certainly here, I’m going to focus on a Windows environment mainly because if you are choosing (or being forced) to use C# for your test solutions, it’s highly likely you are working in a Windows environment. Since Visual Studio Express and/or Community is entirely free, I’m going to assume you are choosing to use that.
Visual Studio
There have been relatively few Visual Studio releases, not all of them named consistently. It all started with Visual Studio 97 (way back in 1997) which then became Visual Studio 6 (in 1998) and then became Visual Studio .NET (in 2002). Since 2005, Microsoft has simply been naming each edition with the year it came out. I’m going to assume you have access to a relatively modern version of either Visual Studio 2010, Visual Studio 2013, or the latest Visual Studio 2015.
Within this year-based versions, there are lots of Visual Studio editions you could possibly be using, including free Express or Community editions as well as the more expensive paid for solutions (Professional, Ultimate or Enterprise depending on your version). I’m going to assume here that you can install the free version (Express or Community). Do note that if you installing fresh, the Community edition for 2015 has replaced the Express editions you would have gotten previously.
I highly recommend that you get the Community Edition.
Xamarin / Mono (MacOS or Linux)
Do note that if you are on a Mac or Linux machine you can certainly use MonoDevelop (now part of Xamarin Platform) to develop C# applications. That being said, you are definitely not going to get the full IDE experience of a Visual Studio in that context but you will absolutely be able to create and execute the same programs.
No IDE / Command Line
It’s also quite possible to do everything without using Visual Studio at all. Microsoft does provide the .NET framework SDK as well as compilers completely free. You can go to the Microsoft.NET home page and ultimately that will lead you the .NET Framework Downloads as well as the targeting packs. You may also want to get the latest Microsoft Build Tools 2015.
Note that .NET is made up of two core attributes: the CLR (Common Language Runtime) and the FCL (Framework Class Library). The CLR is an execution environment for .NET applications. The CLR manages your application while it executes. It’s important to note that the .NET Core CLR, which is open source, will run on non-Windows machines. The FCL is a library of functionality to build applications and, if using this, it’s possible to start using native components that are specific to an operating system. The BCL (Base Class Library) is a subset of the FCL sticking just to the BCL should mean that your C# code can run on any operating system with a CLR, much as your Java code could run on any system with a JVM.
Going this route does require a little bit more work. Just as most Java developers highly recommend you use a free IDE like Eclipse, C# developers recommend you use a free IDE like the Community Edition. Installing the free edition — or one of the paid for editions — gets you all of the .NET Framework SDK and MSBuild material that you need anyway.
NuGet Package Manager
Much like Maven in Java or Rubygems for Ruby, the .NET ecosystem has a package management aspect and one of the key tools for installing packages is the NuGet Package Manager. You can download this and run it from the command line or install it as an extension in Visual Studio.
That said, you are best off simply installing any edition of Visual Studio, including the free ones. That will automatically come with an integrated NuGet interface.
Setting Up Java
To follow any of my Java examples and write your own code, you need the Java Development Kit installed. The standard edition will usually be fine for this purpose. The latest version of JDK can be downloaded from the following link:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
You can make sure everything is set up correctly with the following commands:
java -version javac -version
Build and Dependency Tools
There are various build and dependency tools for Java. I tend to use Maven or Gradle. I won’t cover everything in detail here about each of those tools. Apache has a guide to setting Maven up in five minutes at the following link:
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
If you’re on a Mac, I highly recommend using Homebrew to install Maven (brew install maven). With Debian-style Linux, just use apt (sudo apt-get install maven). Windows provides a zip distribution rather than any sort of installer, although you can use Chocolatey. (See: https://chocolatey.org/packages/maven.)
To check your installation, just do this:
mvn --version
As far as Gradle, which I will sometimes use, on a Mac I would again recommend Homebrew (brew install gradle). On Linux, you’re probably best off installing from source. Check out the Gradle installation doc for (only slightly helpful) more details. If you’re on Windows, you might want to get this via Chocolatey: See https://chocolatey.org/packages/gradle.)
Once installed, check that everything is functioning:
gradle -v
Supporting Tools
When working with Java, it’s generally handy to install a Java-based IDE. The contenders are usually IntelliJ, Eclipse or NetBeans. Take your pick. I tend to focus on Eclipse for many examples, specifically the “Eclipse IDE for Java Developers”. You can get this from here:
http://www.eclipse.org/downloads/
Many of my examples will be utilizing Selenium WebDriver which has built-in bindings for the Firefox browser. So make sure you have a version of Firefox installed.
Firebug is one of the add-ons of Firefox. It’s widely used to inspect HTML elements on a web page. You can get Firebug from the following link:
After you have installed the Firebug add-on to Firefox, it’s time to extend Firebug to have something named FirePath. FirePath is used to get XPath and CSS values of an HTML element on a web page. You can download FirePath from the following location:
https://addons.mozilla.org/en-US/firefox/addon/FirePath/
WebDriver
Now you’ll want to download the WebDriver client library, which you’ll hear referred to as the “language bindings”. Test scripts need a client library with which to interact, or command WebDriver to execute specific user events against a web application being tested on a browser. In my posts, I’ll use Java language bindings to create and execute our automation scripts. For this, you need to download the WebDriver client library:
http://docs.seleniumhq.org/download/
At the time of writing this, you should look at the section: “Selenium Client & WebDriver Language Bindings”. You’ll want to click the “Download” link for Java. It’s a zip file so you’ll want to extract the contents. The contents are going to be a whole bunch of jars in a libs directory.
The good news is that you’ve already downloaded the Firefox Driver. The Firefox Driver comes along with client libraries. But, for other drivers, such as the IE Driver, Safari Driver, Chrome Driver, and so on, you have to download them. You’ll see that stuff under the section “Third Party Drivers, Bindings, and Plugins”.
Setting Up Ruby
For just about any work you do in Ruby these days, you can use either Ruby 1.9.3 or 2.0.0. It is recommended that you go with the 2.0 branch unless you have compelling reasons to stay at 1.9.
NOTE: A 1.8.x version of Ruby is not supported for many gems you’ll likely want to use.
As for the basics:
- Install Ruby 1.9.3 or 2.0.0.
- Install RubyGems.
- Install a Ruby switching system (optional).
- Install the DevKit (only if on Windows).
- Install the Bundler management system.
Setting up Ruby on Windows, Linux and MacOS X
There are plenty of directions on the Ruby downloads page so I don’t see a need to repeat all of that here. Do note that if you are on Windows, your best option is to use an official RubyInstaller package. That will also get you RubyGems.
Once you have installed Ruby, open a command prompt and check the version of your Ruby interpreter:
ruby -v
Like most languages Ruby has its own mechanism for managing libraries of code. RubyGems is the software used to manage gems. Gems are basically libraries of code. Capybara is a Ruby gem. The RubyGems application typically gets installed when you first install Ruby but it is worth double-checking if you have it.
gem -v
You should make sure you have a version greater than 1.5 and ideally somewhere in the 1.8 range. If you do have a version that is below 1.5, simply update you RubyGem system:
gem update --system
Assuming you want to run multiple versions of Ruby (or even just a single version of Ruby that is well-managed), you’ll probably want to use the Ruby Version Manager or rbenv. As far as RVM, which is by far the more popular choice, there is plenty of documentation on the RVM installation page so I will not cover all that here. You might also want to check out the minimalist chruby that a lot of people like.
About as close as you’ll get to RVM on Windows is a tool called Uru, which takes over for a previously popular tool known as pik.
If you are on Windows, you will require the Ruby Development Kit, available via the RubyInstaller downloads page. The reason for this is because you will, in some cases, need a C/C++ environment when gems have to be built natively. The good news is once the kit is installed, you really don’t have to worry about it again. There are plenty of instructions for installing the DevKit so I won’t rehash those here.
I will note that I strongly recommend extracting to c:\DevKit. The actual directory is not so important but you want it in a relatively easy to access path and, ideally, a path without spaces in the names.
Install Command Line Tools (Optional)
Many of the Ruby tools you will use are command line tools. This is because many of these tools are designed to provide a minimal interface, such that they can serve as a back-end tool for a variety of user interface designs. The emphasis on the command line also gives these tools a great deal of flexibility in terms of specifying execution parameters. This reliance on a command line interface also allows many Ruby applications to run on Windows, MacOS X, and Linux platforms without having to worry about graphical libraries. Finally, the command line execution allows many tools, like RSpec, Cucumber, Capybara and so on, to be incorporated into other solutions, such as build management or continuous integration tools.
Since every system out there comes with a command line or terminal interface, you might be curious what I mean by installing them. This is mainly for Windows users. Windows obviously already comes with a command line tool (cmd.exe). While serviceable, it doesn’t always fully support ANSI X3.64 with Xterm color extensions. That matters because tools like RSpec and Cucumber can provide color output. That color output is not required but it can be helpful.
On Windows, if you do want color output at the command line, you can check out a tool called Ansicon, which is short for ANSI Console. This is an open source tool that serves as an alternative command line editor which can better process ANSI escape sequences, particularly those that send color sequences.
Beyond just getting color, you might actually want a better command line interface. In that case, I recommend checking out Console2. With that tool, you can set up a particular console view that calls Ansicon as well as other command line tools you may have. There are lots of other perks to it as well, such as the ability to have multiple command line interfaces open in a tabbed view.
Even better, perhaps, you might try out ConEmu. This tool has ANSI escape handling built in so you shouldn’t even need Ansicon. That being said, I find this a little more cumbersome than I usually need.
Installing Browser Driver Servers
This section is only relevant if you need to run your automation against a browser, even more specifically, against Internet Explorer or Chrome. Firefox support tends to be built into most solutions based around Selenium, which is just about all of them. That said, you should do these steps! Firefox changes much too rapidly lately to keep up with and so you will find yourself using Internet Explorer and Chrome periodically. Beyond that, if you plan on doing cross-browser automation, these steps are necessary.
In the steps below you will download executable files. Those files can be placed anywhere that is part of your PATH environment variable. I recommend creating a new directory, placing the files in there and then adding that directory to your PATH environment variable. This will keep those files in one location in case they need to be updated.
To get tests to run against Internet Explorer, you’ll need the IEDriverServer. You will see two files with the words “IEDriverServer” at that location. These will currently be zip files. One is 64-bit. The other is 32-bit. Which one do you download?
On recent Windows systems, like Windows 7 and 8, Internet Explorer comes as both a 64-bit version and a 32-bit version. Whichever file you choose above will be the browser that Symbiont uses and that holds for pretty much any other automation tool out there. What this means is that even if you have a 64-bit operating system, you are certainly able to use the 32-bit IEDriverServer. Symbiont will then use the 32-bit version of Internet Explorer. Similarly, if you use the 64-bit IEDriverServer, Symbiont will use the 64-bit version of Internet Explorer.
To get tests to run against Chrome, you’ll need the ChromeDriver. The driver files are specific to operating system. They also have version numbers. You will want to choose the latest driver for your operating system.
Once you have downloaded the files for either server, simply extract the files to the location you have decided to put them in. This location must be available via the environment PATH.
Installing Gems
Most of what you do in Ruby development or when using Ruby applications is to use gems, which are packaged libraries of functionality or entire applications.
On Linux or Unix systems, you may need to preface any gem-based commands with “sudo”.
If you do not have direct access to the Internet, but instead go through a proxy server, you will have to set the HTTP_PROXY environment variable. For example, on Windows that means you will have to do three commands rather than just one:
set http_proxy={your proxy}
gem install {whatever}
set http_proxy=
The reason for unsetting the proxy at the end is so that it does not conflict with other operations you may be doing.
Bundler is ubiquitous within the Ruby ecosystem. You can use it to manage your project’s dependencies. Bundler is itself a Ruby gem and applies a layer of dependency management on top of RubyGems. With Bundler you can essentially isolate specific gem dependencies to a specific project. That way even if there are multiple versions of a given gem installed on your machine, only the one that is relevant for your project will be used. It does so by installing all the gems in an application’s Gemfile.
Many Ruby projects will include a Gemfile that allows someone to get all of the necessary dependencies to use the project. Bundler itself is a gem and can be installed with the following:
gem install bundler