We’ll continue our Things You Should Know About Appium blog series with a focus on C# (or CSharp). In short, C# is a multi-paradigm programming language and was created to be as simple, modern and general-purpose as possible, not forgetting the object-oriented approach as a programming language. For Appium, C# is really a valid option and we’ll walk you through here with some basic things.
Before jumping into our today’s topic: we’ve received tons of great feedback and ideas for blogs to be part of this series, so please keep them coming, you definitely have been heard, and we’ll keep producing useful and step by step material for your needs. Now, let’s go!
Download Our Complete Appium Beginner’s Guide to Set Up a C# Testing Environment Today
Similar to the syntax of Java, C# is a widely used language for all kinds of programming and scripting needs. The primary reasons to choose C# as THE scripting language for Appium tests are those benefits and advantages also close to what Java programmers have. The recommended full IDE for C# scripting is Visual Studio for Windows and or if you use MAC/UNIX there are other options available as well. Anyway, I do recommend using an IDE, as having any type of smart auto-completion mechanism with proper listings of available methods is always a win and makes your day easier.
Without further ado, let’s get started with the C# sample! Take a look at this first and prepare your environment in the same way as we’ve done with the prior examples on Java and Python.
First, let’s start with those desired capabilities.
For Visual Studio you should make sure that the NUnit Test Adapter is installed through the Extension Manager. In order to install the NUnit Test Adapter in the Extension Manager, select Tools -> Online Extensions (panel on left) and then locate NUnit Test Adapter and highlight it.
For running those tests, you can use Test Explorer. Using UNIX, first download the dependencies of the solution by following these steps:
1. Download all dependencies – with one command
We use NuGet to install a package using specific resources. Using our example, you have a folder “Test123” that includes packages.config. The following components will get fetched:
<packages>
<package id="Appium.WebDriver" version="1.3.0.1" targetFramework="net45" />
<package id="Newtonsoft.Json" version="7.0.1" targetFramework="net45" />
<package id="NUnit" version="2.6.4" targetFramework="net45" />
<package id="Selenium.Support" version="2.46.0" targetFramework="net45" />
<package id="Selenium.WebDriver" version="2.46.0" targetFramework="net45" />
</packages>
To get these components installed, use the following command line:
> nuget install Test123/packages.config -OutputDirectory packages
Now, all required bits and pieces are downloaded, installed and you are ready to build the package.
2. Build Test Package
Use the following command to build the test package for your local setup:
> xbuild
3. Run your tests
Then, use the following command to run the recently built test package:
> nunit-console Test123/bin/Debug/TestdroidAndroidSample.dll
What about those test results?
When you begin your Appium testing with Bitbar Testing, you may notice that by default the portal doesn’t show detailed information regarding your test run successes and failures. The reason for this is, of course, that you need to upload the results first!
Why is this so? During a test run, Appium server doesn’t keep count of succeeding and failing test cases. To put it simply, the server’s job is to take in the commands from the client, execute those commands on the connected mobile device and finally report back to the client the results of those commands. Any test suite formatting and reporting are all handled by the client. So any test results will only exist on the client-side.
Let’s take a look at how you can upload those test details to the cloud to ensure everything is shown properly in the right context.
Uploading your test results XML to the cloud
From our help pages, the test results upload goes like this:
Uploading your Test Suite output to the Cloud
If your test suite generates a JUnit XML results file, you can upload the XML to the cloud. When you do this, all your test cases and their statuses will be shown on the Bitbar Testing’s Test Run view and the complete test report is downloadable. A couple of good tips to ensure everything goes fine:
> Add the testdroid_junitWaitTime Desired Capability in your TestScript.
> Get Appium sessionId from your script using driver.session_id. Note that this only can be done after the WebDriver connection has been properly established.
> After your test run has finished, and JUnit XML has been generated, use cURL to upload the XML to the cloud:
curl -s -F result=@"/absolute/file/path/TestOutput.xml" "http://appium.testdroid.com/upload/result?sessionId=<sessionId>"
But wait, Webdriver in C# doesn’t seem to have driver.session_id!
Yikes! That’s what I was wondering too while I was preparing this post. After some digging though, I found a way to print out the session id.
Fortunately, this Stack Overflow post has a well-working solution to make the session_id value available. Here what you should do – first add the function for session_id:
public class CustomRemoteDriver : RemoteWebDriver
{
public CustomRemoteDriver(Uri remoteAddress, ICapabilities desiredCapabilities)
: base(remoteAddress, desiredCapabilities, TimeSpan.FromSeconds(400))
{
}
public String getSessionId()
{
return this.SessionId.ToString();
}
}
Then, you should add testdroid_junitWaitTime in desired capabilities:
capabilities.SetCapability("testdroid_junitWaitTime", 120);
...
driver = new CustomRemoteDriver(new Uri("http://appium.testdroid.com/wd/hub"), capabilities);
Finally, use the following line to print out the session id:
Console.WriteLine (driver.getSessionId());
These edits that I did to print out the session id can be also found here.
So far so good.. and TIPS!
One last thing to consider is that Bitbar Testing expects the test results XML file to be in JUnit format, as the desired capability leads to believe. NUnit and JUnit result files are very close to each other, so using some converter is more than possible. For example, here’s an open-sourced Jenkins plugin for NUnit reporting, which includes JUnit conversion as one of its functionalities.
Great! I hope you learned something about how to get in started or if you use it already, make things working smoother with your Appium and Bitbar Testing combination on C#.
We’ll continue on Friday about the wonderful world of Appium and Ruby! Stay tuned – and Happy Testing!