Selenium API at a glimpse

If we take a look at all commands available in most common Appium's drivers, we will probably not find anything suitable for data exchange. Let us consider for example the Javascript Driver and all commands exposed there: there is nothing that specifically focuses on exchanging information. Just automation. The same goes for the other drivers, there is no specific method that enables data exchange between the test and the app being tested. So what do we do? We try to achieve that result by ourselves.

One method to exchange data

There is only one method in Selenium which I did not mention in the previous section, which is actually the solution to our problem here:

executeScript(script, args)
executeAsyncScript(script, args)

The ones above are the names of the methods available in the WebDriver's W3C specification. Those two commands allow the test to execute some Javascript code in the (webview-based) app. It might not sound so promising but there is one very important thing about those two guys: they can return stuff!

Returned value

There is some complexity behind how those 2 functions are implemented in whatever WebDriver, however the W3C defines the basics of their business logic as well as the protocol to use to successfully return a value to the caller. The W3C specification is very generic, so here I will try to make things a bit easier. According to the specification, when executeScript is invoked (the same goes for executeAsyncScript), the following must happen:

1. The caller must provide the script in a string.
2. The string is parsed when reaching the browser's window object (in a webview-based app, remember that we have a browser) and set as the body of a Javascript function object acting on the global context and taking as input the arguments passed to executeScript.
3. The function is executed in a safe block where its return value is captured or any exception can be caught as well.
4. In case of exception, the error is set as the response status.
5. In case a value is returned, it is parsed and sent back in the response's value field. Response's status field is set to success.

Also, when a value is to be returned by the function, the following must happen:

1. If the value is undefined or null, null is returned.
2. If value is a number or a string, then no further operation is done and the value is returned as it is.
3. If value is a DOM element, then the corresponding WebElement is constructed and returned.
4. If value is an array, then return an array whose elements are built by following these algorithm for each element.
5. If value is an object consisting of custom properties, then return the same object by applying this algorithm to each property in it.

So as you can see, we can return something from our tests. By invoking a script which returns some interesting information, we can actually send requests and have data in return. However things are not so easy.

No everybody implements the full specification

The problem is that not every driver implements the algorithms I just mentioned 100%, this is especially true when it comes to the algorithm used to build the returned value. Basing on my experience, so far it is safe to return numbers or strings. When it comes to whole objects or DOM elements, sorry to say, it is not certain that what we get back from the device is exactly what we were expecting. For this reason, for the sake of test stability ad reliability, it is better to always keep in mind the following:

Always return simple types only, this will always ensure successful data exchange.

Returning complex data: JSON serialization

So, how can we exchange complex data if we can only return strings or numbers from our app? Actually we do not really care about returning numbers, strings are just fine! The answer to our question is the following:

To enable data exchange, it is possible to send and receive objects as string via JSON serialization.

The following picture will probably provide a better description of the basic idea.

We can make Javascript queries to send via executeScript, and get a JSON string back. When our query is executed, we must take care of stringifying the returned value and return it instead of the JSON object. Once we get the string in our test, we can use one of the many JSON parsing libraries available on the web to convert it into a dynamic structure or an hash table (dictionary).

Possible scenarios

If the idea is clear, then we can move on picturing some possible scenarios. Where might we ever need to exchange data? Consider the following examples:

• Getting the possible values that a user can select from a combo box.
• Getting the chosen value from a list of possible options when we are not using form controls in our page, but some HTML or jQuery complex control.
• Getting the value typed by the user in an editable div of one page of your hybrid app.
• Checking return value of an AJAX call to the server.

Keeping on listing possible scenarios would be meaningless, you will sure find a situation when data exchange comes into need believe me, especially if your tests are a bit more complicated than usual automation and your apps have articulated user stories.

An example: values in a list

Let's consider a real case and see data exchange in action. Our app deals with restaurants and is able to locate the most famous ones close to where the user is. In a page of our app, after the user issues the search command, we are able to see the list of possible restaurants in a radius of 200 meters. We want to test that some restaurants are displayed when the user is located in a specific area. In our page, the list of restaurants will look like the following:

<ol id="item_selection">
  <li class="item" data-id="i0463">Item 1</li>
  <li class="item" data-id="i3957">Item 2</li>
  <li class="item" data-id="i9248">Item 3</li>
  <li class="item  data-id="i3451" data-selected">Item 4</li>
</ol>

Remember that our app is an hybrid app, so it relies on HTML. Here we could have used a simple combo box, however my point is proving that we can exchange data coming from every part of your DOM, not just form controls.

Serializing with Javascript

In our test we need to get access to the list, in particular we want the ID (available as a data attribute) of the restaurant which is selected. How can we do this? In our test we can have the following code.

[TestMethod]
public void TestSelection() {
  AppiumDriver driver = this.Driver; // The test class will host the driver (assuming connected)

  // Retrieving from device
  object ret = driver.ExecuteJavascript(@"
    // Javascript executed in an anonymous function on the webview
    var ret = {};

    var ol = document.getElementById("item_selection");
    if (ol == null) {
      ret.status = -1; // List not found
      ret.message = "Could not find list";
      ret.value = null;
      return JSON.strigify(ret);
    }

    // The ol element could be found
    var lis = ol.getElementsByTagName("li");
    if (lis == null) {
      ret.status = 0; // No items
      ret.message = "No items in list";
      ret.value = null;
      return JSON.strigify(ret);
    }

    // We have the list, need to locate selected one
    ret.status = 1
    ret.message = null;
    ret.value = {};
    ret.value.id = null;
    ret.value.text = null;
    for (var i = 0; i < lis.length; i++) {
      if (lis[i].dataset.selected != null) {
        ret.value.id = lis[i].dataset.id;
        ret.value.text = lis[i].textContext; /* Use innerText on IE */
      }
    }

    return JSON.strigify(ret);
  ");

  if (ret == null) {
    throw new InvalidOperationException("Appium had problems executing script");
  }

  // If we can get to here, then serialized javascript object should be here
  string json = (string)ret;

  // Getting the object, this function will be implemented later 
  // and the type returned will be specified as well
  var obj = this.ParseJSON(json);
  // Code will continue later on...  
}

As you can see, in our invocation, we pass a Javascript function which will be executed on the device by Appium. Serialization is performed by means of JSON.stringify, which is an API introduced not so long ago in ECMAScript.

Deserializing with every other language, e.g. C#

How do we parse JSON in our test? The nice thing of JSON is that all programming languages have at least one API to parse it. C# is no difference and it provides something called JavascriptSerializer in the System.Web.Script.Serialization namespace. This class however gets a bit tricky to use when just deserializing a JSON string which was not serialized from a concrete type using the same class (which is exactly our case). For this reason we are going to rely on .NET's WCF and use the DataContractJsonSerializer which implies a bit more code to be written, but your tests will have a better and more consistent shape.

The first thing we need is a C# representation of the object we will use to exchange data. In WCF we achieve this by means of Data Contracts which are a WCF-specific concept describing the information being sent between two endpoints. The following code will actually describe the ret structure we used in the previous Javascript chunk.

[DataContract]
public class SelectedItemReturnStruct {
  private int status;
  private string message;
  private SelectedItemValue value;

  /// Data member's Name must match Javascript object ret's property
  [DataMember(Name = "status", IsRequired = true)]
  public int Status { 
    get { return this.status; } 
    set { this.status = value; } 
  }

  /// Data member's Name must match Javascript object ret's property
  [DataMember(Name = "message", IsRequired = true)]
  public string Message { 
    get { return this.message; } 
    set { this.message = value; } 
  }

  /// Data member's Name must match Javascript object ret's property
  [DataMember(Name = "value", IsRequired = true)]
  public SelectedItemValue Value { 
    get { return this.value; } 
    set { this.value = value; } 
  }
}

[DataContract]
public class SelectedItemValue {
  private string id;
  private string text;

  /// Data member's Name must match Javascript object ret's property
  [DataMember(Name = "id", IsRequired = true)]
  public string Id { 
    get { return this.id; } 
    set { this.id = value; } 
  }

  /// Data member's Name must match Javascript object ret's property
  [DataMember(Name = "text", IsRequired = true)]
  public string Text { 
    get { return this.text; } 
    set { this.text = value; } 
  }
}

You will also need to include System.Runtime.Serialization namespace for getting access to DataContract and DataMember attributes.

The key on data contracts is that they provide a mapping between objects of different types. the DataContract attribute tells the framework that an instance of a class can be created as long as the other entity sends an object of a class implementing the same contract. In this case, we will receive a JSON string describing an object with some properties. The serializer will use the contract to associate each Javascript property to a property of our class. The framework will look for matching names, that is why we must ensure that the properties we use in the Javascript object will match those in DataMembers in our classes.

We are now ready to perform deserialization by implementing method ParseJSON introduced in the previous code.

public SelectedItemReturnStruct ParseJSON(string json) {
  DataContractJsonSerializer js = new DataContractJsonSerializer(typeof(SelectedItemReturnStruct));
  MemoryStream ms = new MemoryStream(System.Text.ASCIIEncoding.ASCII.GetBytes(json));

  SelectedItemReturnStruct ret = (SelectedItemReturnStruct)js.ReadObject(ms);
  ms.Close();
  
  return ret;
}

The previous code assumes that you included in your test project the assembly System.Runtime.Serialization and that you included the following namespace in your file: include System.Runtime.Serialization.Json;. Namespace System.IO will also be needed.

We can now complete our test method we left incomplete before.

[TestMethod]
public void TestSelection() {
  // We were here...
  var obj = this.ParseJSON(json);
  
  if (obj.Status == -1) {
    // No list
    throw new InvalidOperationException("List could not be found!");
  }
  if (obj.Status == 0) {
    // No items
    Assert.Inconclusive();
  }

  // A list could be found and items as well
  if (obj.Value == null) {
    // No item marked as selected ==> Nothing to test
    return;
  }

  string id = obj.Value.Id;
  string text = obj.Value.Text;
  // Test whatever you want from now on...
}

It was not that difficult and this pattern can be implemented for whatever type of objects you need to exchange.

The views and opinions expressed in this blog are those of the authors and do not necessarily reflect the official policy or position of any other agency, organization, employer or company.

This post is for developers who actually knows about Appium but never approached to it. Whatever the reason for which you never gave it a try, I am gonna spend few lines about what you should expect from Appium. Do you need it? Is it going to be any good for you? Let's discover it together.

Also keep in mind that this is not a final verdict on Appium, this post is an early evaluation from the point of view of a developer who has been using it, intensively, for a short time until now; thus every answer I will provide is implicitly preceded by an IMHO!

We will go through 21 different questions you can find down below.

0. Appium, WebDriver, Selenium, Appium drivers and Cordova... What are they?
1. Do I need Appium?
2. How difficult is it to set up a working environment?
3. What is Appium's strongest point?
4. What is Appium's weakest point?
5. Which language should I use to write my tests?
6. What types of tests are suitable for Appium?
   1. Can Appium be used for all my tests?
   2. I am writing my tests and it is getting very difficult... When should I give up?
   3. What does a typical Appium test look like?
7. What is Appium's most considerable limitation?
8. How active is Appium?
9. How about performance?
10. Which approach is the best? Testing on real devices or real simulators/emulators?
11. What platforms are supported?
12. Do I need a server machine to run tests on Appium?
13. I already have platform-specific tests for my app, what should I do to migrate to Appium?
    1. How much time does it take to write a test in Appium?
    2. Any tips or tricks to speed up my test writing activity or my migration process?
14. What test frameworks are supported by Appium?
15. Can I interact with my apps using Javascript while I am testing with Appium?
16. How can I exchange data between my test and the app I am testing?
17. What are the most difficult scenarios to test with Appium?
18. I don't want to set up a whole infrastructure for my tests and I don't want to spend money on HW. Can Appium help me?
19. I need to debug Appium, is it difficult?
20. I build my apps with Cordova, is it supported by Appium?
21. What are the basic commands that I can use in the Selenium protocol?
22. I want to run my tests in a multithreaded environment, any problems with that?

Q0 - Appium, WebDriver, Selenium, Appium drivers and Cordova... What are they?

I like calling this Question 0 because it is like a general summary of what I am going to deal with in this Q&A session. If you are familiar with all these names, just jump to Question 1.

These 5 guys are sort of the most important building blocks when it comes to app development and testing with Appium (Appium does not cover the development phase). Since I want to keep this short and straightforward, I am going to explain what they are and how they relate to each other in a simple diagram.

As you can see the whole thing is not so immediate, but the figure above provides a good picture of how pieces are to be assembled together.

Q1 - Do I need Appium?

The answer to such a question is always: "It depends on what you need!". So the actual question becomes: "Which conditions make Appium suitable for me?". The most important assumption is that you are developing apps (pretty obvious I know). If you are developing an app for a specific platform (and have no intention of supporting others in future), Appium is not really required and this is basically the answer you are looking for. Appium becomes meaningful only when you have apps targeting more than one platform (Windows, Android or iOS to cite some). Appium becomes essential if you have a webview-based app (necessarily) targeting many platforms out there.

Q2 - How difficult is it to set up a working environment?

The assumption is that Appium comes with a not-so-tiny documentation, so users are not really left alone. However it is not so straightforward to set up Appium to work on a Windows or Mac machine (did not try on Unix so far). In my experience, instead of installing the GUI-based application, it is much better to install the command-line application (which is released more often). Also beware [sudo], as Appium will surely bite you back late in time if you installed it as a [superuser] (this is probably the clearest point in the documentation).

Q3 - What is Appium's strongest point?

Appium is based on Selenium which is an HTTP protocol by Google designed to automate browsers. The idea is actually very nice as automating an app (especially a webview-based one) is not so different (in terms of required APIs) from automating a browser. Appium is also designed to encourage a 2-tier architecture: a machine runs the test written in one language ([csharp], [ruby], [javascript] are only a few among the many supported ones) and another one (the test server) actually executes it. Furthermore the WebDriver protocol targets scalability (because based on HTTP), this makes Appium very scalable as well; remember that you will need to write your test once, Appium will be in charge of executing it on more platforms.

Q4 - What is Appium's weakest point?

Open source software is great, however it naturally comes with some downsides which nobody is to be blamed for: unreliability is probably one of the most undeniable. My test suites need to run many tests every day and those tests must be stable (it means they should fail only when the product, or the test has a defect). However it took me much time to build layers on top of Appium to make my tests stable. This is especially true when it comes to synchronizing your tests with the automation: your test issues a command which translates into an automation command by Appium causing an interaction on the device; a command returns when after it has been issued, not when the interaction is actually over! For this reason you will probably find yourself adding delays to your tests (if you are doing things in the wrong/most-straightforward way) or developing synchronization layers on top of your test APIs (the good approach).

Q5 - Which language should I use to write my tests?

This is probably the best thing about Appium: you can write your tests in any language. Since Appium is nothing more than an HTTP server, a test which needs to be interfaced with Appium can simply use HTTP libraries to create HTTP sessions. You just need to know the Selenium protocol in order to compose the right commands and that's it!

Do not reinvent the wheel

However, as you can imagine, there are already some libraries doing this for the most common languages and development frameworks out there: C#, [dotnet], [java], Ruby, [python] and Javascript are just few examples; and they all are open source projects. So far I have been using C# thanks to the .NET Appium Driver and had no problems to interface with Appium (I actually had different problems).

Q6 - What type of tests are suitable for Appium?

When it comes to testing, especially webview-based apps, there are a lot of scenarios that can be tested also depending on the feature coverage you want to ensure. Appium is pretty handy for testing scenarios that users will go through when using your app. But if you need to test more than UX simple interactions, then Appium will become a limitation. Think about features like keyboarding. It is not so easy when complex touch/keyboard mixed scenarios are involved, the probability of a false failure is high; do not misunderstand me on this: I am not saying it is impossible to do, just not so easy as you might think!

Another little nightmare with Appium is exchanging data. When your test needs to exchange data with your app (especially in the incoming direction), you will need to play some tricks. So always consider that sending and receiving information is not that straightforward. It is not Appium's fault, the WebDriver specification was designed for automating stuff, not exchanging data! You can get more info in Question 16.

Q6A - Can Appium be used for all my tests?

This is an implied question in this question. The answer is No (in general). As I said before Appium is not suitable for all types of tests you might want to write (this depends on the functionalities you need to cover). There are some scenarios that can be difficult to test and some of them are so platform specific that you will need to write some suites just for Android or iOS for example. Remember that you can always get to do something no matter how hard it is, so you can test all your difficult scenarios using Appium, but always keep in mind one question: is it worth the time and the pain? Having Appium testing some scenarios leaving a few tests to other approaches is fine too! World is not black and white!

Q6B - I am writing my tests and it is getting very difficult... When should I give up?

There are a few clear symptoms which will let you know things are getting weird and wrong when writing your tests in Appium; when you meet one of the following conditions, stop and consider not using Appium for those tests. 

• You realize that some tests must be run just for a specific platform, or you are putting many conditionals to execute part of a test depending on the platform.
• The functionality you want to cover in your test is available only when your app is deployed on a specific platform.
• Your test must cover a fix for a specific platform.
• The test is difficult to write because you need a lot of interaction with the app.
• A simple interaction needs more than 10 commands.

Q6C - What does a typical Appium test look like?

When you start writing tests for Appium, if your suites do not require data exchange with your app or other not so common features, you will probably end up with something like the code shown below.

namespace AppiumTest {
// The app should show an error message when login is performed with non valid credentials.
[TestMethod]
public void LogInWithInvalidCredentials() {
    string usernameTextboxId = "un";
    string passwordTextboxId = "pw";
    string submitButtonId = "submit";
    string errorMsgboxId = "errBox";

    string address = "http://localhost/appium-srv:4723/wd/hub";
    DesiredCapabilities capabilities = new DesiredCapabilities();

    try {
        AppiumDriver appiumDriver = new AppiumDriver(address, capabilities, 60);

        // Locate the username textbox
        IWebElement usernameElement = appiumDriver.FindElementById(usernameTextboxId);
        Assert.IsNotNull(usernameElement, "Element could not be found but supposed to be there");
        usernameElement.Clear();
        usernameElement.SendKeys("Invalid user");

        // Locate the password textbox
        IWebElement passwordElement = appiumDriver.FindElementById(passwordTextboxId);
        Assert.IsNotNull(passwordElement, "Element could not be found but supposed to be there");
        passwordElement.Clear();
        passwordElement.SendKeys("Invalid password");

        // Locate the submit button
        IWebElement submitElement = appiumDriver.FindElementById(submitButtonId);
        Assert.IsNotNull(submitElement, "Element could not be found but supposed to be there");
        submitElement.Click();

        // Wait because the app must contact the security server for logging in
        Thread.Sleep(5000);

        // Check the error message
        IWebElement errorMsgElement = appiumDriver.FindElementById(errorMsgboxId);
        Assert.IsNotNull(errorMsgboxId, "The error message should be shown");
    } catch (Exception e) {
        throw new Exception("An error occurred with Appium", e);
    }
}

This code shows a test for a webview-based app going through a login scenario with invalid credentials. For this example I considered [csharp] and the .NET Appium Driver developed by the Appium team.

Q7 - What is Appium's most considerable limitation?

Hand down my chin starting thinking and mumbling. If I had to provide one single thing you should be aware of about Appium before starting using it, it would surely be: multiple session handling. Since Appium is a server, it serves HTTP requests; you might have two different computers running a test each against the same Appium server: what happens? As for now, Appium does not support this scenario and the second test will be aborted. This is a considerable limitation, because no queuing system comes with Appium. If you need to support multiple sessions, you will need to implement this feature by yourself.

Q8 - How active is Appium?

Appium is available on GitHub and there you can find all you need. The Appium team is responsible for developing many different subsystems revolving around Appium (like APIs for different languages), thus I can tell you that this product is alive and very active. The team is also pretty well responsive and once you open an issue you will find a reply after no more than 36 hours (this ETA comes by my personal experience). The community around Appium is also pretty large and growing every month.

Q9 - What about performance?

Appium is not a huge application and requires very little memory. Its architecture is actually pretty simple and light as Appium acts like a proxy between your test machine and each platform automation toolkit. Once up and running, Appium will listen to HTTP requests from your tests; when a new session is created, a component in Appium's Node.js code called _proxy_ will forward these Selenium commands to active platform drivers. In the case of Android for example, Appium will forward incoming commands to the [chromedriver] (90% of cases, Appium will not even change commands while routing them), this happens because ChromeDriver supports WebDriver and Selenium. For this reason Appium will not allocate much memory itself, you will see a lot of memory being allocated by other processes like [adb], ChromeDriver or the iOS automation toolkit (called by Appium while testing and automating).

Q10 - Which approach is the best? Testing on real devices or simulators/emulators?

This is a tough question because both options offer different levels of testability and flexibility when testing. There are also many problems associated with each. So my answer will be again: "It depends on your needs!".

Tests on real devices

Running test on a device is, always in my opinion, the best solution because it offers a testing environment completely aligned with the running environment: tests run on those devices where your apps will be used  once published on stores. However devices must be connected to the Appium server via USB at least, and this is not always a very nice thing. ADB has a known issue for which a device disconnects after a while (even though it remained plugged all the time): because of this your tests might fail after a while and Appium will report that a device could not be found! I had to write a component which resets ADB after some time so that devices will not disconnect.

Tests on emulators or simulators

On the other hand emulators/simulators will never disconnect from Appium. They also offer nice options like the ability of choosing the orientation or other hardware-related configurations. However your tests will run much slower (sadly, my tests ran 3 times slower) and do expect some crazy behavior from the Android emulator which sometimes shuts down unexpectedly. Another problem is that emulators tend to allocate a lot of memory.

Q11 - What platforms are supported?

Appium currently supports Android and iOS, no support for Windows unfortunately.

Q12 - Do I need a server machine to run tests on Appium?

No! Appium promotes a 2-tier architecture where a test machine connects to a test server running Appium and automating the whole thing. However this configuration is not mandatory, you can have Appium running on the same machine where your test runs. Instead of connecting to a remote host, your test will connect to Appium using the loopback address.

Q13 - I already have platform-specific tests for my app, what should I do to migrate to Appium?

Unfortunately there is not a magic formula to translate your tests into Selenium tests. If you developed a test framework on different layers and observed good programming principles, you should be able to act on some components in your tests in order to migrate your suites to Appium. Your current tests are going to be easy to migrate if they are already using an automation framework or something close to a command-based interaction. Truth being told, you will probably need to write your tests from the beginning, what you can do is actually reusing your existing components.

Q13A - How much time does it take to write a test in Appium?

Of course it depends by the test. If your test simply runs a scenario, it will take as many commands as the number of interactions needed to be performed (thus very few lines). If you are trying to exchange data, then your test will take more time for sure and the test will also become difficult to read.

Q13B - Any tips or tricks to speed up my test writing activity or my migration process?

Here is one piece of advice. Since your tests will mostly consist in automation tasks (if this condition is not met, you might want to reconsider using Appium), make interactions reusable! Do not write the same sub-scenarios twice in your tests, make a diagram of what your scenarios are and split them in sub activities; you will get a graph where some nodes are reachable from more than one node. So make those tasks parametric and call them in your tests! This will make your test writing experience better even when you need to migrate from existing tests (hopefully you already did this activity for your existing suites).

Q14 - What test frameworks are supported by Appium?

Appium does not support test frameworks because there is no need to support them! You can use Appium with all test frameworks you want. NUnit and .NET Unit Test Framework are just a few examples; you will write your tests using one of the drivers for Appium; thus your tests will interface with Appium just in terms of an external dependency. Use whatever test framework you want!

Q15 - Can I interact with my apps using Javascript while I am testing with Appium?

Yes! Selenium has commands to execute Javascript instructions on your app from your tests. Basically you can send a JS script from your test to your app; when the commands runs on Appium, the server will send the script to your app wrapped into an anonymous function to be executed.

Returning values

However your Javascript interaction can get more advanced as your script can return a value which will be delivered to your test when the HTTP response is sent back by Appium once your Javascript has finished running. However this scenario comes with a limitation: your Javascript can send back only primitive types (integers, strings), not complex objects. The limitation can be overtaken by passing objects as JSON strings or by modifying Appium's or Selenium's code to support specific objects.

Q16 - How can I exchange data between my test and the app I am testing?

Appium, actually the WebDriver specification, is not made for exchanging data with your app, it is made to automate it. For this reason, you will probably be surprised in finding data exchange not so easy. Actually it is not impossible to exchange data with your app , however it will require you to build more layers of testability.

What data exchange is

When I say "data exchange" I am not referring to scenarios like getting or setting the value of a textbox. I am also not referring to getting or setting the value of an element's attribute. All these things are easy to achieve in Appium as Selenium provides commands just for those. By "data exchange" I mean exchanging information hosted by complex objects stored in different parts of your webview-based app like the window object. Consider when you dispatch and capture events, your app can possibly do many things and the ways data flows can be handled are many. Some objects might also have a state and the state machine behind some scenarios in your app can be large and articulated. For all these reasons you might experience problems when testing.

Testability layers

In order to make things better, as a developer, what you can do is adding testability layers to your app. The logic behind this approach is simply having some test-related objects in your app which are activated only when your tests run. I learned about this strategy from one of my colleagues Lukasz and such a technique can be really powerful. Enable your testability layers when testing in order to make data exchange easy. 

Exchanging data through Javascript

Selenium provides commands do execute Javascript on the app, it is also possible to execute functions and have them return data (only basic types). If you exchange JSON strings it should be fine as JSON.stringify(str) will turn your JSON string into an object on the app side, while on the test side (depending on the language you are using), you can rely on hundreds of libraries to parse the string you receive.

Q17 - What are the most difficult scenarios to test with Appium?

As I already mentioned in Question 6 and Question 16, Appium is not suitable for all types of tests. There is a particular scenario that will make your tests more difficult to write: data exchange. I already said it but I will repeat the same thing because it is very important: Appium and WebDriver are designed to automate stuff... not to exchange data with them. So what if we need to exchange information with our app during tests? Should we give up on Appium and write our tests manually for each platform? I am not saying this, but there are cases where you should consider this option (not nice I know, but if the effort of writing tests for Appium is higher than the benefits, than just throw Appium away).

Appium is very nice because it will let you write tests once for all platofrms instead of writing as many tests as the numbers of platforms you need to support. So if you need to exchange data with your app while testing it and this data flow is the same for all platforms, then you should probably keep on using Appium and find a way to write a layer on top of it to handle data. Depending on your needs this might take time, but, in my experience, it is really worth it.

Q18 - I don't want to set up a whole infrastructure for my tests and I don't want to spend money on HW. Can Appium help me?

If you think about it, what really is required from you is writing tests. Then the fact that you must deploy an Appium server somewhere is something more. If you want to skip this part, you can rely on some web services that already deployed a whole architecture of Appium servers for your tests. Most of them are online labs and they support Selenium and Appium. Among the most famous you can find: SauceLabs.

Q19 - I need to debug Appium, is it difficult?

No really! Appium is a Node.js application, so it is Javascript in the essence. The code is available on GitHub and can be downloaded in few seconds as it is small and not so complex. Depending on what you have to debug, you will probably need to go deeper in your debugging experience, however there are some key points where setting a breakpoint is always worth: the proxy component is worth a mention. In appium/lib/server/proxy.js you can set a breakpoint in function doProxy(req,res), that will be hit everytime commands are sent to platform-specific components to be translated into automation commands.

Q20 - I build my apps with Cordova, is it supported by Appium?

Cordova is a very famous system that enables you to develop webview-based apps for all platforms in short time. Appium does not explicitely say that Cordova is supported, even though they do it implicitely as some examples using apps built with Cordova are provided on Appium's website. So the answer is that Cordova should not be a problem. Why am I being so shy about it? Because anything can happen and it actually happened to me!

Cordova and Appium are two different projects that are growing up separately and independently, of course a mutual acknowledgement is present, but both teams do not really talk to each other when pushing features. So problems can occur (I am currently dealing with a problem concerning Cordova's new version which is causing my tests to fail).

Q21 - What are the basic commands that I can use in the Selenium protocol?

Google's Selenium provides a collection of commands to automate your app. With those commands you can basically do the following:

• Locate web elements in your webview-based app's pages by using their ids or class names.
• Raise events on located elements like Click().
• Type inside textboxes.
• Get or set located element's attributes.
• Execute some Javascript code.
• Change the context in order to test the native part of your app, or the webview. If your app uses more webviews, you can switch the context to the webview you desire. If your webview has frames or iframes inside, you can change context to one of them.
• Detect alert boxes and dismiss or accept them. Be careful about this functionality, I experienced some problems.

Q22 - I want to run my tests in a multithreaded environment, any problems with that?

Yes! You need some special care when using Appium in a multithreaded environment. The problem does not really rely on the fact of using threads in your tests: you can use them but you must ensure that no more than one test runs at the same time against the same Appium server. As I mentioned, Appium does not support multiple sessions, and unless you implemented an additional layer on top of it to handle this case, some tests might fail.

No problems if i's the same sessions!

If, in the context of the same test, you run multiple threads issuing different commands at the same time, some problems might occur but they relate to the state of your app, Appium should not really have problems with that because those commands are received from the same test session! 

So... Is Appium worth a try?

Definitely yes! Actually, I think that Appium is worth the choice. Today many developers started using it and a lot of test frameworks are relying on this technology. I think Appium will grow even more next months, so my suggestion is to keep an eye on it, WebDriver and Selenium as they will probably become a de-facto standard in web-application testing.

Enterprise level

That being said, let me also tell you that Appium, IMHO, is still not so mature for testing complex features in your apps. I said it already: exchanging data is not easy and Appium is not to be blamed because based on Selenium; however I have a good feeling about this; exchanging information with apps while testing is important and this necessity will probably lead the community to create layers on top of Appium or, who knows, Appium might solve this itself. 

Please keep in mind...

Before leaving you, just one more thing. All my feedback and experience I shared here today relates to technologies at their current versions (or those I have been using so far). As things change, I will publish more posts, but everything I assessed so far relates to Appium 1.2.4 and Cordova 3.6.3.

The views and opinions expressed in this blog are those of the authors and do not necessarily reflect the official policy or position of any other agency, organization, employer or company.

What is Appium?

Appium is used to automate tests on devices with the main objective of allowing users to write tests once, and run them on different platforms and devices with no further effort. The main idea behind Appium can be easily grasped by looking at the following figure.

The basic workflow to test with Appium is the following:

1. Tests are written using different languages (Appium supports many of them: Ruby, C# and Java to list some).
2. A server running Appium (the test server) is configured and made available on a certain network location.
3. Devices, or their corresponding simulators, are connected to the test server.
4. Tests are run from the test machine.

Please note that in the last point I said: "tests are run from..."; this is our point of entry to understand how Appium works. The client/server pattern helps Appium achieve multi-platform testability, once a test is written it is executed in the client/test station. Thanks to Google's JSON [seleniumwebdriver], Appium is able to have tests send commands to devices through the test server.

When writing Appium tests, the code will simply perform HTTP calls to the server which will translate those meta-commands into device-specific actions sent to the device to test. Commands are essentially user interactions with the app like clicking an interface component, swiping on the screen, scrolling onto a particular area or performing a specific gesture. Appium also supports execution both on real devices and simulators.

A little problem with naming

So if somebody asked us: "Where does my test run on?" we would probably find some uneasiness when replying. In fact we launch our tests from a client machine, but they actually run on our devices (or their simulators). So how to put things in order? The solution is in how we describe the process. The following statement can help:

Tests are actually run from a test client and they are executed on a device or its simulator via the test server.

Writing your first test in C#

In Appium's philosophy, a test for an app should be written only once, then it is supposed to run on different platforms with no further work.

The first thing we take care of is locating all configuration settings needed to pass to the server in order to run our tests. Appium's API consists of some important classes, one of these is DesiredCapabilities. This class defines the most important parameters to have the server run tests in the correct testing environment; in order to keep track of these settings, let's create a wrapper that we can reuse.

public sealed class TestCapabilities { 
  /// Tracking platforms  
  public enum DevicePlatform {
    Undefined,
    Windows,
    IOS,
    Android
  }

  public string BrowserName      { get; set; }
  public string FwkVersion       { get; set; }
  public DevicePlatform Platform { get; set; }
  public string PlatformVersion  { get; set; }
  public string DeviceName       { get; set; }
  public string App              { get; set; }
  public bool   AutoWebView      { get; set; }
  public string AutomationName   { get; set; }

  public TestCapabilities() {
    this.BrowserName     = String.Empty;
    this.FwkVersion      = String.Empty;
    this.Platform        = DevicePlatform.Undefined;
    this.PlatformVersion = String.Empty;
    this.DeviceName      = String.Empty;
    this.App             = String.Empty;
    this.AutoWebView     = false;
    this.AutomationName  = String.Empty;
  }

  public void AssignAppiumCapabilities(ref DesiredCapabilities appiumCapabilities) {
    appiumCapabilities.SetCapability("browserName",     this.BrowserName);
    appiumCapabilities.SetCapability("appium-version",  this.FwkVersion);
    appiumCapabilities.SetCapability("platformName",    this.Platform2String(this.Platform));
    appiumCapabilities.SetCapability("platformVersion", this.PlatformVersion);
    appiumCapabilities.SetCapability("deviceName",      this.DeviceName);
    appiumCapabilities.SetCapability("autoWebview",     this.AutoWebView);

    // App push (will be covered later)
    if (this.App != String.Empty)
      appiumCapabilities.SetCapability("app", this.App);
  }

  /// Converting to string the platform (for Appium)
  private string Platform2String(DevicePlatform value) {
    switch (value) {
    case DevicePlatform.Windows:
      return "win"; /* TODO: Need to write your own extension of Appium for this */
    case DevicePlatform.IOS:
      return "iOS";
    case DevicePlatform.Android:
      return "Android";
    default:
      return "";
    }
  }
}

In the most simplistic scenario, you will run your tests against the same server. However in a more enterprise-level context, you might need to deploy more test servers depending on the tests you have. It is good practice to keep track of your servers.

public static class TestServers {        
  public static string Server1 { get { return "http://192.168.2.23:3445/wd/hub"; } }
  public static string Server2 { get { return "http://192.168.2.24:3446/wd/hub"; } }
  public static string Server3 { get { return "http://192.168.2.36:3432/wd/hub"; } }
  public static string Server4 { get { return "http://192.168.2.36:3436/wd/hub"; } }
  public static string Server5 { get { return "http://192.168.2.38:3445/wd/hub"; } }
  public static string Server6 { get { return "http://192.168.2.39:3445/wd/hub"; } }
}

First step done!

Your first test suite and all dependencies you need

Our final test is ready to be crafted now. Before writing it, however, we need to download the Selenium WebDriver for C# so that we can send commands to the Appium server using C#.

1. Go to Selenium WebDriver download page and download the driver for C#.
2. Unzip the folder and show its content.
3. Locate the .NET version you need and copy that folder into your test project's dependency directory.
4. Reference all assemblies in your project.

One more thing we need is the Appium Dot Net Driver in order to get some more tools.

1. Go to Appium Dot Net Drive's page on GitHub and download it in your test client (where your test solution is located).
2. Unzip the content and navigate to the "appium-net-driver" project folder.
3. Open the project in Visual Studio and build it.
4. Locate output assemblies (a "bin" folder should be created) and copy them into your test's project.
5. Add references to these assemblies in your test solution.

Now we can get to the test suite. The code below provides a basic template to have an Appium test ready to run. Here I am not providing a specific unit test implementation, read Appium's API in order to learn how to use automation tools for that.

namespace AppiumTests
{
  using System;
  using Microsoft.VisualStudio.TestTools.UnitTesting; /* We use .NET UnitTest Fwk, but any unit test fwk can be used */
  using AppiumTests.Helpers;
  using AppiumTest.Framework;
  using OpenQA.Selenium; /* Appium is based on Selenium, we need to include it */
  using OpenQA.Selenium.Appium; /* This is Appium */
  using OpenQA.Selenium.Appium.Interfaces; /* Not needed for commands shown here. It might be needed in single tests for automation */
  using OpenQA.Selenium.Appium.MultiTouch; /* Not needed for commands shown here. It might be needed in single tests for automation */
  using OpenQA.Selenium.Interactions; /* Not needed for commands shown here. It might be needed in single tests for automation */
  using OpenQA.Selenium.Remote;

  [TestClass]
  public class AppiumTestSuite
  {
    private AppiumDriver driver;

    private static Uri testServerAddress = new Uri(TestServers.Server1);
    private static TimeSpan INIT_TIMEOUT_SEC = TimeSpan.FromSeconds(180); /* Change this to a more reasonable value */
    private static TimeSpan IMPLICIT_TIMEOUT_SEC = TimeSpan.FromSeconds(10); /* Change this to a more reasonable value */

    [TestInitialize]
    public void BeforeAll()
    {
      DesiredCapabilities capabilities = new DesiredCapabilities();
      TestCapabilities testCapabilities = new TestCapabilities();

      testCapabilities.App = "";
      testCapabilities.AutoWebView = true;
      testCapabilities.AutomationName = "";
      testCapabilities.BrowserName = String.Empty; // Leave empty otherwise you test on browsers
      testCapabilities.DeviceName = "Needed if testing on IOS on a specific device. This will be the UDID";
      testCapabilities.FwkVersion = "1.0"; // Not really needed
      testCapabilities.Platform = TestCapabilities.DevicePlatform.Android; // Or IOS
      testCapabilities.PlatformVersion = String.Empty; // Not really needed

      testCapabilities.AssignAppiumCapabilities(ref capabilities);
      driver = new AppiumDriver(testServerAddress, capabilities, INIT_TIMEOUT_SEC);
      driver.Manage().Timeouts().ImplicitlyWait(IMPLICIT_TIMEOUT_SEC);
    }

    [TestCleanup]
    public void AfterAll()
    {
      driver.Quit(); // Always quit, if you don't, next test session will fail
    }

    /// 
    /// Just a simple test to heck out Appium environment.
    /// 
    [TestMethod]
    public void CheckTestEnvironment()
    {
      var context = driver.GetContext();
      Assert.IsNotNull(context);
    }
  }
}

Done! The test suite is ready to be run. As you can see I am using NUnit as unit test framework, however you can use whatever test framework you like; Appium is not affected by this and will work as expected.

Setting up an Appium test server

In the first part of this article I described the client/server nature of Appium; however this does not mean that you need two computers for testing your app, a standalone deployment is possible and consists of having the Appium test server installed and running on the same machine where tests will run from. Since I want to cover a generic scenario, this tutorial will consider the following architecture:

• A Windows test client.
• A Mac test server.
• One Android and one Apple tablet.

The network configuration is depicted by the following figure.

The first thing we need to do is installing the Appium server, then we will take care of devices.

Installing the Appium server

Our scenario covers Appium server on Mac, but the installation process is quite the same for Windows and Unix as well. However please take care of one important thing: the server needs to be connected to devices or run their simulators, for all platforms (Windows, iOS and Android) vendors provide different SDKs; however not all SDKs are available for all OSs, so your testing options will be limited as per the following matrix.

(*) Appium still does not support tests on Windows: it means that tests cannot be run on Windows simulator and on Windows mobile devices; just reporting for future possible extensions.

As it is possible to see, a single server will never be able to allow tests on all possible device platforms. Another important thing to know about Appium is that it can be installed on all OSs reported in the matrix above.

To install Appium, follow these steps:

1. Go to the Appium website.
2. Download the latest version of the software according to your OS.
3. Run the installer and complete all steps (almost no configuration).
4. Once done, launch Appium and click on the gear icon on the top-left side of the screen.
5. Make sure that the "Server Address" field is set to the local address "0.0.0.0" and the "Port" field next to it is st to "4723" (or set it to another valid non-used port).

And done! There is no further configuration to perform. Next step is configuring devices or their simulators. Here as well it is important to understand an important concept: either you are going to test on a real device or on its simulator, you will need that device SDK. Appium will take advantage of the SDK to connect to the simulator or the real device connected via USB. Also please be aware that I will not enter in detail for installing SDKs (off topic in this article).

Testing on iOS

Since you will run on the iOS simulator, you need to have it running before running your tests (it is not always necessary though).

1. Launch XCode from your machine and open your app's project.
2. Navigate to XCode -> Open Developer Tool -> iOS Simulator and bring up the simulator.

To run tests on the iOS simulator, follow these steps in the Appium server:

1. On the top-left corner, click on the radio button below the Apple icon to activate Appium for Apple devices.
2. Click on the Apple icon (top-left) and bring up the "iOS Settings" window.
3. Check "App Path" if unchecked and enable the textbox next to it.
4. Locate field "App Path" and type the absolute path to the .app file of your app. Everytime you compile your XCode project, in the "build" folder, a file called <project-name>.app is generated; you need to get that file's path.
5. Be sure that field "BundleID" is unchecked.
6. Since we are testing on a tablet, be sure to select "iPad" in field "Force Device". If you want to test on a different device, choose the most appropriate one for your needs.
7. Be sure field "UDID" is unchecked.

You did it! The server is ready to accept incoming requests from your tests. Run your server by clicking on the top-right button "Launch". After that, switch to your test client and run your tests; as soon as they execute you will see, on the server, the iOS simulator coming up and perform all tasks.

Testing on real device

To test on a real Apple device (iPad or iPhone), do not touch the configuration you used to test on the simulator and do the following on the test server:

1. Connect your device to the server machine via USB.
2. Be sure to set up correct provisioning profiles for your devices. Follow Apple's documentation about provisioning profiles.
3. On your app's XCode project, navigate to Windows -> Organizer and bring up the "Organizer" window.
4. On the left side, locate your device under "Devices" group and select it.
5. Your device details are shown. Locate field "Identifier" and copy & paste it on a note file, you will need it later.
6. On the left pane, expand your device to show more options. Locate "Applications" and click on it.
7. In the "Applications" window for your device, locate your app and copy & paste its BundleID for later. The BundleID is the name reported below (small font) your app's name. 
8. On Appium, stop the server if it's still running and click on the Apple icon (top-left) and bring up the "iOS Settings" window.
9. Check the "BundleID" field and paste there the text you just saved in step 7.
10. Check the "UDID" field and paste there the 160bit hex value you saved on step 5.

You're ready to go! Start the server and run you tests; this time you will see your app being deployed and running on the device.

Testing on Android

The Android SDK has a very strict virtual environment for simulating; the user must correctly install all needed libraries according to the API level and the Android system version on which the app is supposed to run. The latter is very important in those cases where your apps have a minimum requirement in terms of OS support; thus be sure, in such scenarios, to choose the correct version. Follow these steps to correctly set your AVD (Android Virtual Device):

1. Open your Eclipse environment on your project.
2. Refer to the Android documentation to set up you AVDs.

To run tests on the Android simulator, follow these steps on the Appium server:

1. On the top-left corner, click on the radio button below the Android icon to activate Appium for Android devices.
2. Click on the Android icon (top-left) and bring up the "Android Settings" window.
3. Check "App Path" if unchecked and enable the textbox next to it.
4. Locate field "App Path" and type the absolute path to the .apk file of your app. Everytime you compile your Eclipse project, in the "bin" folder, a file called <project-name>.apk is generated; you need to get that file's path.
5. Be sure that fields "Package", "Use Browser" and "Device Name" are unchecked.
6. Select the correct version for field "Platform Version" according to your Android API version. 

You're done! Run the server by clicking on the top-right button "Launch". After that, switch to your test client and run your tests; as soon as they execute you will see, on the server, the Android simulator coming up and perform all tasks.

Testing on real device

To test on a real Android device, leave your configuration as it was when you set up Appium to work with the simulator and proceed as follows:

1. Connect your device to the server machine via USB.
2. Click on the top-left button displaying the Android icon and bring up the "Android Settings" window.
3. Uncheck field "Launch AVD".
4. Check field "Device Name".
5. Close the Android simulator if it is still running.

This is it! When you run your tests, you will now see your app being deployed and running on your Android device.

App push from the test client

One concept is important to understand about Appium when it is configured as we did so far:

A test is bound to a single app per each server.

It means that it is not possible to set up an Appium server for testing two different apps. So: "Where is the problem?", some of you might ask; actually the problem is when we want to create a real infrastructure for testing apps in the context of real enterprise. In such a context it would be nice to set up a server for testing more than one app, however we cannot do this if we need to set the app to test at server side. Appium, however, allows developers to set the app to test from tests; it means that we can transmit the path (on the server) to the app file that should be used to deploy the app itself; only one more capability is needed: "app".

1. Get back to the test suite we just wrote before, locate method GetCapabilities.
2. Add one more capability as shown below.

private DesiredCapabilities GetCapabilities() {
  // Other settings...
  capabilities.App = "<absolute-path-to-app>"; /* App-Push */

  return capabilities;
}

3. Switch to the server and stop it.
4. Open your device configuration (click on the top-left Apple or Android icon).
5. Uncheck field "App Path".
6. Start the server again.

With this simple but powerful capability, we are now able to write tests covering common base functionalities across different versions of the same app. It is also possible to use the same server to run different tests for different apps. Remember that you need to pass the absolute path to your app file (the file type changes according to the device platform) in your test server machine's filesystem, not the client.

App push + upload

I know some of you think that it would be also nice to have tests physically send the app file to the server. Appium does not support this, however nothing can stop you from using SSH or other remote connection tool to upload your app file to the server machine before running tests.

The views and opinions expressed in this blog are those of the authors and do not necessarily reflect the official policy or position of any other agency, organization, employer or company.

https://onedrive.live.com/redir?resid=28F0C4E5A0596D8%2143506

Basics on proxies

A proxy is a generic entity used to act as a (possibly transparent) third party component in the context of a whatever interaction. However, when using the term proxy, people usually refer to web proxies. A web proxy basically is a web server which intermediates in HTTP communications between different hosts. The basic idea behind a proxy is having host A communicate to host B through a server (the proxy): this architecture enables several scenarios, useful for developers, that I am going to illustrate.

There are basically two possible ways a proxy can be configured, but it is good to start from the basic scenario when no proxy is involved.

A normal HTTP session involves a requestor and a web server. An HTTP request is sent to the web server (the requestor needs to know the address of the web server), which replies back with an HTTP response. In this model, a proxy can be placed in different locations: this will determine the type of proxying strategy being used.

Reverse proxy

A reverse proxy is an Internet-facing device acting as an intermediary on our side of the LAN, handling requests and dispatching them to one of our hosts in the same network. This scenario is illustrated below.

As you can see, the proxy is placed right after the LAN gateway and dispatches messages to the server. This is the most common configuration for a proxy due to the as well very common scenario it supports: hiding resources. A reverse proxy in such a configuration can be an interface for the world outside. When a client requests a web page or something else through HTTP (this is also valid for other application protocols), it will not use the IP address of our web server, but the IP address of our proxy; we can then protect our important servers in the LAN giving them private addresses as our proxy will dispatch messages to them. The final result is that our servers will not be exposed to the Internet, only the proxy will, but a proxy usually stores no significant data (differently from our servers), thus if it is successfully hacked, no data leakage will occur and our information will still be safe and not corrupted.

The image above shows one of the real usages of a reverse proxy: not only can it hide resources, it is also able to act as a dispatcher to many servers in our LAN. In this case the dispatching can be performed based on the URL provided in the HTTP request; consider you are developing a web application to download and stream music: www.listentomusic.com. We do not want our music files to be publicly exposed on the network, so we use a reverse proxy as shown in the picture. However we also provide music information other than the music itself, so when the user accesses our web site it will typically download pages from our web application server, however when he wants to listen to music, addresses will have the following format: www.listentomusic.com/listen/<song-name>. Our proxy will then make a request to the media streaming server providing, in the HTTP header, all security parameters needed to get access to music files. When the user wants to access music info, he can type www.listentomusic.com/artist/<name-of-artist> or www.listentomusic.com/song/<name-of-song>, this will have the proxy redirect the request to the data center server instead.

Load balancing

Another very common strategy in networking involving reverse proxies is load balancing; a reverse proxy can be really handy in this case. Consider the situation depicted in the picture below: our service is expected to provide responses to a very high number of requests, in this case chances are that a single server is not enough, since we are a small business company, we cannot really afford a high-level performance server, however we can always rely on the Dividi et Impera approach: we can buy more average-performance servers and have the proxy balance the load.

A reverse proxy improves security, resource protection and maintenance as well. Say for example that you need to migrate your server to a different system, your server will probably be down for 12 hours at least. No problem, you can create a cloned low-performance server for one day and redirect traffic there while you are migrating your real server: you will keep you service alive without users noticing as the proxy will redirect traffic on a different location while serving requests to the same public address.

Forward proxy

A forward proxy can be considered as the opposite of a reverse proxy: it is an Internet-facing device which redirects our requests to specific sources.

The purpose of such an architecture is having client's requests redirected (transparently to the client) to another location from the original one. Why? There are possible rationales.

• Anonymity This represents the 95% of reasons for which one would use a forward proxy and, sadly speaking, seeking for anonymity generally means that someone is willing to perform not so nice actions on the web. A forward proxy, in fact, will not let the server know who really is looking for a specific resource as the proxy will be seen as the requestor. Think of a forward proxy like a trader, it will protect your identity acting as an intermediate unit between you and the server.
• Source selection This application is not so common and is meaningful if you are a developer or a tester. If we were developing a distributed system, we could use a proxy as a traffic router to direct all requests to a specific source. This can be good when performing stress tests for example.

Open proxies

Forward proxies became very famous on the web when private subjects or companies started offering free forward-proxying service. Not so much time ago, network administrators used to block users' access to social networks, like Facebook, Google+ or Twitter, in corporate or university campus LANs. Usually this common practice was meant to improve bandwidth and prevent employees or students from taking too much leisure time on blogging or socializing during work/study time.

Achieving this block is easy: firewalls would not let in or out packets whose source/destination IP address is part of a blacklist. Well, we all know people are very smart especially when it comes to breaking the rules, in fact a solution to this problem (if we want to call it so) came very fast: using a forward proxy to access social networks.

The figure above shows how it is possible to deceive the university firewall when getting access to our social network by relying on a tunneling proxy. An open proxy is in fact a tunneling proxy: it takes all requests and simply forwards them to a specific destination without changing them (only the source address will be changed). If we use a proxy, our request will not be directed to the social network's server, but to the proxy; the firewall will not block our request because it is not part of the blacklist. Also, when we receive the reply, we will receive it form the same exact proxy, this time as well the firewall will let the pack go through.

Few years ago there were many proxies available on the web to let people connect to social networks, however network administrators got a little smarter and firewalls today are also able to inspect the HTTP content of TCP/IP packets. Instead of relying on addresses, firewalls inspect the content of packets, thus they can access the HTML header in order to find traces of social networks. But it's not like this little war is over, more techniques have been implemented to work around these blocking systems. By the way, today employers prefer not to prevent their employees from accessing social networks, the same goes for students in universities: it is way cheaper to let everybody have their leisure time instead!

Proxy design and implementation

Designing a proxy is not so difficult, in this section I am going to describe the most common principles to follow when developing a proxy so that it works as expected.

Handling communications

A web proxy must ensure transparency and allow a communications between two hosts to take place when it is actually acting as a Man In The Middle. The figure below illustrates how a proxy should handle requests and responses.

When a proxy receives a request it must hold it and, in the meantime, fire a new request to the real destination. After host A sends a request to the proxy (we are not covering a Man In The Middle attack, so host A is perfectly aware of the existence of a proxy), the proxy will take some time to hold the request and create a new HTTP request to host B. Host B will replies after a while (time necessary to retrieve the requested resource) and then the HTTP response lands on proxy, which will change the source address with its own and forward it to host A.

Ensuring association

The other thing a proxy should take care of are associations between requests and responses. Since a proxy is a server, it will process more than a request; for this reason a proxy must be able to correctly manage all session couples (hostA-Proxy and Proxy-hostB). In the figure shown before, we can see that a proxy handles two different sessions both sharing an address: the proxy; once a request is handled in the first session, it must be saved until the session with destination host terminates. It is important not to mix up sessions and keeping all couples consistent. Other than a communication problem this is a security issue as well.

The figure above shows a proxy serving request using a queuing system. This can be quite a naive approach but it works: all requests are saved in a queue as they arrive. Whenever ready to process a new request, after terminating processing a full session, the proxy will take care of the next one. As all queues, it is important to know well the expected throughput so that queues can be sized correctly, otherwise the probability of data loss due to full queues can become very high.

The approach shown in the picture above is now the opposite: multi-threaded proxy. Dispatching threads as requests arrive is a good idea; however there is a limit in threading due to shared resources. Modern proxies use thread pools in order to handle thread creation. It means that a new thread is not created every time a new requests arrives, modern algorithms evaluate the machine status and decide whether new threads should be created or reused.

The views and opinions expressed in this blog are those of the authors and do not necessarily reflect the official policy or position of any other agency, organization, employer or company.