On no longer wanting to depend on ExpectedConditions in my C# Selenium WebDriver tests

Those of you that have been writing tests with Selenium in C# for a while might have noticed that as of version 3.11, some often-used things have been marked as deprecated, most notably the PageFactory implementation and the ExpectedConditions class. For those of you that have not read the motivation behind this, here is the rationale behind it, as written by Jim Evans, core contributor to the Selenium C# bindings.

These implementations have been moved to a new location and have been made available as separate NuGet packages (DotNetSeleniumExtras.PageObjects and DotNetSeleniumExtras.WaitHelpers, respectively). As of the time of writing this blog post, however, there’s still no new maintainer for this GitHub repository, meaning that there’s no support available and no certainty as to its future.

Notice of ExpectedConditions class being deprecated, as visible in Visual Studio

And while that is no problem yet, since you can still use the deprecated classes from the Selenium bindings or use the DotNetSeleniumExtras packages, I think it’s a risk to keep on relying on code that is effectively unsupported.

In my case, for PageFactory, that’s not a problem, since I don’t typically use it anyway. For ExpectedConditions, however, it’s a different story. When I’m writing and teaching Selenium automation, I’m pretty much still following the general approach I described a couple of years ago in this post. It still works, it’s readable, easy to maintain and explain and has proven to be effective in many different projects I’ve worked on over the years.

However, it also relies on the use of ExpectedConditions, and that’s something that is bothering me more and more often.

So, while preparing for a training session I delivered recently, I started looking for an alternative way of writing my wrapper methods in C#. And it turns out that C# offers an elegant way of doing so, out of the box, in the form of lambda expressions.

Lambda expressions (also known as anonymous functions) is a function that’s not bound to an identifier, but instead can be passed as an argument to a higher-order function. The concept stems from functional programming (it has been a long while since I’ve done any of that, by the way) but has been part of C# for a while. By the way, lambda expressions are available in Java too, from Java 8 onwards, for those of you not working with C#.

Let’s look at an example. Here’s my implementation for a wrapper function around the default Selenium SendKeys() method that takes care of synchronization and exception handling using ExpectedConditions:

public void SendKeys(By by, string valueToType)
      new WebDriverWait(_driver, TimeSpan.FromSeconds(Constants.DEFAULT_TIMEOUT)).Until(ExpectedConditions.ElementToBeClickable(by));
    catch (Exception ex) when (ex is NoSuchElementException || ex is WebDriverTimeoutException)
         Assert.Fail($"Exception occurred in SeleniumHelper.SendKeys(): element located by {by.ToString()} could not be located within {Constants.DEFAULT_TIMEOUT} seconds.");

Here’s the same wrapper, but now passing a lambda expression of our own as an argument to the Until() method instead of a method in ExpectedConditions:

public void SendKeys(By by, string valueToType)
    WebDriverWait wait = new WebDriverWait(_driver, TimeSpan.FromSeconds(Constants.DEFAULT_TIMEOUT));
        IWebElement myElement = wait.Until<IWebElement>(driver =>
            IWebElement tempElement = _driver.FindElement(by);
            return (tempElement.Displayed && tempElement.Enabled) ? tempElement : null;
    catch (WebDriverTimeoutException)
        Assert.Fail($"Exception in SendKeys(): element located by {by.ToString()} not visible and enabled within {Constants.DEFAULT_TIMEOUT} seconds.");

From the Selenium docs, we learn that the Until() method repeatedly (with a default but configurable polling interval of 500 milliseconds) evaluates the lambda expression, until one of these conditions applies:

  • The expression returns neither null nor false;
  • The function throws an exception that is not in the list of ignored expressions;
  • The specified timeout expires

This explains why I created the lambda expression like I did. Before clicking on an element, I want to wait until it is clickable, which I define as it being both visible (expressed through the Displayed property) and enabled (the Enabled property). If both are true, I return the element, otherwise null. If this happens within the timeout set, I’ll clear the text field and use the standard SendKeys() method to type the specified value. If a WebDriverTimeOutException occurs, I’ll handle it accordingly, in this case by failing the test with a readable message.

Yes, implementing my helper methods like this makes my code a little more verbose, but you could argue that this is a small price to pay for not having to rely on (part of) a library that has been deprecated and of which the future is uncertain. Plus, because I define all these helpers in a single class, there’s really only one place in my code that is affected. The Page Objects and my test code remain wholly unaffected.

This GitHub repository contains a couple of runnable example tests that are written against the ParaBank demo application. This is an updated version of the solution described here. An updated version of this last blog post is coming soon, by the way, so that it reflects some opinions and preferences of mine that have changed since I wrote that one. No longer having to rely on ExpectedConditions, as I discussed here, is but one of those changes.

An introduction to REST API testing in Go with Resty

Just over a year ago, I was working in a team that, among other things, was responsible for developing and running some microservices that delivered data to a front end. It turned out those services were written in Go, a programming language that I had vaguely heard of before but never worked with.

However, as the tester and automation engineer in that team, I was tasked with writing some automated checks that could be made part of the build pipeline, so I decided that it would be a good opportunity to pick up some new skills and tools and write those checks in the same language. Now, Go is a relatively young language, first appearing in 2009. This also meant that the tool set around Go isn’t as mature as in other languages like Java or C#. Despite that, I was able to get these tests up and running fairly quickly.

Recently, I stumbled upon Go again (can’t really remember when and where, not that it’s important) and thought it would be a good idea to revisit the language. In this blog post, I’d like to show you some examples of how to write and run tests against a REST API in Go. The API I’m using for this is once again the Zippopotam.us API.

Now, Go has support for testing built-in, so unlike languages like Java or C#, you don’t need to add a unit testing framework to your project. All you need to do is import the testing library in your code, have your Go file name end with _test.go, write a method with a name starting with Test, run

go test

and you’re good to go. For setting up requests and capturing, parsing and checking the response, I found the Resty library to be very useful. It’s pretty similar to the requests library in Python, or RestSharp for C#. Here’s what a first test, checking the response status code for a correctly formatted GET requests to our API, looks like in Go with Resty:

func Test_GetUs90210_StatusCodeShouldEqual200(t *testing.T) {

	client := resty.New()

	resp, _ := client.R().Get("http://api.zippopotam.us/us/90210")

	if resp.StatusCode() != 200 {
		t.Errorf("Unexpected status code, expected %d, got %d instead", 200, resp.StatusCode())

Note that I’m not going to explain all the nuts and bolts of Go and its syntax here. If you’re interested to learn more, I’d recommend this book or taking the Tour of Go.

If we run this test using the go test command, you’ll see that it passes:

Each test method takes an argument of type T (from the testing library), which is used to manage test state. What might strike you as odd (it did for me) is that there’s no assertion in this test like you would expect if you’re familiar with unit testing frameworks like JUnit, NUnit or pytest. The reason is simple: they don’t exist in the Go testing library. The people behind Go have their reasons for it, but this is something I don’t really like. I prefer using assertions, because they make my test code easier to read, plus it saves me from writing all these if-then-else statements myself.

Fortunately, other people thought the same, so there are third party libraries available that let you write assertions. I chose to use Testify, because it not only provides assertions, it also allows you to create test suites and use setup and teardown methods in a way similar to other languages. Here’s what the same test looks like, but now using an assertion provided by Testify:

func Test_GetUs90210_StatusCodeShouldEqual200(t *testing.T) {

	client := resty.New()

	resp, _ := client.R().Get("http://api.zippopotam.us/us/90210")

	assert.Equal(t, 200, resp.StatusCode())

Much better, in my opinion. Now, let’s see if we can also check a response header value:

func Test_GetUs90210_ContentTypeShouldEqualApplicationJson(t *testing.T) {

	client := resty.New()

	resp, _ := client.R().Get("http://api.zippopotam.us/us/90210")

	assert.Equal(t, "application/json", resp.Header().Get("Content-Type"))

That is pretty straightforward. Next, how about extracting and checking a response body value? The easiest way to do that in Go is to unmarshal (deserialize) the response body into a struct (a data structure in Go). If we want to do that, we first have to define the struct like this:

type LocationResponse struct {
	Country string `json:"country"`

This defines a struct LocationResponse with a single element Country. The json:”country” tag tells Go that it should populate this element with the value of the country element in the JSON response body. We don’t have to worry about the other elements in the response, those simply will not be mapped (unless you need them in a check, then you’ll need to add them to the struct, too).

Now, we can write a test that maps the response body to a struct of type LocationResponse and then check the value that has been assigned to the Country element:

func Test_GetUs90210_CountryShouldEqualUnitedStates(t *testing.T) {

	client := resty.New()

	resp, _ := client.R().Get("http://api.zippopotam.us/us/90210")

	myResponse := LocationResponse{}

	err := json.Unmarshal(resp.Body(), &myResponse)

	if err != nil {

	assert.Equal(t, "United States", myResponse.Country)

As a final example, I’d like to show you how to create a setup method for creating an initial state for all the tests in a suite. Here’s how to do that using Testify and its suite module:

type ZippopotamUsTestSuite struct {
	ApiClient *resty.Client

func (suite *ZippopotamUsTestSuite) SetupTest() {
	suite.ApiClient = resty.New()

func (suite *ZippopotamUsTestSuite) Test_GetUs90210_StatusCodeShouldEqual200() {
	resp, _ := suite.ApiClient.R().Get("http://api.zippopotam.us/us/90210")

	assert.Equal(suite.T(), 200, resp.StatusCode())

First, we create a struct ZippopotamUsTestSuite that contains all the objects shared by all tests. In this case, all I need is a Client (a class in Resty) called ApiClient (in Go the variable name comes before the data type when you declare a new variable). We can then write a method called SetupTest() that does the setup for all of our tests, and we use (suite *ZippopotamUsTestSuite) to make our existing test methods part of the suite we defined.

To actually run our test suite, we need to create a ‘regular’ test method and pass the suite we have created to the suite.Run() method of Testify:

func TestZippopotamUsSuite(t *testing.T) {
	suite.Run(t, new(ZippopotamUsTestSuite))

If you omit this step, go test will not run the test suite!

All in all, given my experience is mostly with Java, C# and Python, I’ve found writing tests in Go to be a little more cumbersome than in those languages. However, with the right tool set, it is perfectly possible to write readable and well-structured tests in Go, as the examples in this blog post hopefully demonstrated.

I’m keen to further explore writing tests (and other software) with Go, so I’ve recently started learning the language through this Coursera course series. It’s mainly targeted towards those wanting to become a Go developer, and there isn’t much talk of testing, but I’m looking forward to it anyway. I’ll try to share some more tips and tricks on writing tests in Go in the near future.

If you want to read more about writing tests in Go, I recommend you reading this article by Alex Ellis or going through this tutorial.

All code that I’ve used in this blog post can be found here.

Writing tests for RESTful APIs in Python using requests – part 3: working with XML

Recently, I’ve delivered my first ever three day ‘Python for testers’ training course. One of the topics that was covered in this course is writing tests for RESTful APIs using the Python requests library and the pytest unit testing framework.

In this short series of blog posts, I want to explore the Python requests library and how it can be used for writing tests for RESTful APIs. This is the third blog post in the series, in which we will cover working with XML request and response bodies. Previous blog posts in this series talked about getting started with requests and pytest, and about creating data driven tests.

While most REST APIs I encounter nowadays work with JSON as the preferred data format for request and response body bodies, from time to time you’ll encounter APIs that work with XML. And since XML is a little more cumbersome to work with XML in code compared to JSON (not just in Python, but in general), I thought it would be a good idea to show you some examples of how to create XML request bodies and how to parse and assert on XML response bodies when you’re working with the requests library.

For the examples in this blog post, I’ll be using an operation from the ParaBank REST API that can be used to submit bill payments. It’s available at


and takes, next to two query parameters specifying the source accountId and the bill amount, an XML request body containing specifics about the person to whom the payment is sent, i.e., the payee. Not surprisingly, this request body is sent to the API provider using an HTTP POST.

Creating XML request bodies using strings
I’d like to show you two distinct approaches to creating XML request bodies. The first one is the most straightforward one, but also the least flexible: creating a method that returns a string object containing the XML body:

def fixed_xml_body_as_string():
    return """
        <name>John Smith</name>
            <street>My street</street>
            <city>My city</city>
            <state>My state</state>

Note the use of the triple double quotes to allow you to declare a multi-line string. Of course, instead of hard-coding our XML request body in our code, we could also read it from an XML (or text) file stored somewhere on our file system. The result is the same.

If we want to pass this XML request body to our API, we can do that like this:

def test_send_xml_body_from_string_check_status_code_and_content_type():
    response = requests.post(
        headers={"Content-Type": "application/xml"},
    assert response.status_code == 200
    assert response.headers["Content-Type"] == "application/xml"

Note that we explicitly set the Content-Type header of the request to application/xml to make sure the provider understands that the request body should be interpreted as XML. Sending the XML request body is done by assigning the return value of our method returning the XML as a string to the data parameter of the requests post() method.

To check that our request has been received and processed successfully, we assert that the response status code equals 200 and that the response Content-Type header has a value of application/xml. We’ll take a closer look at the actual XML response body later on in this post.

Creating XML request bodies using ElementTree
The other approach to working with XML request bodies is to programmatically build them. Python contains a powerful library to do this, called ElementTree. We can import this into our module using

import xml.etree.ElementTree as et

Since an XML document is essentially a tree with a root node with child nodes attached to it, we start creating our XML request body by defining the payee root node:

payee = et.Element('payee')

We can then define an element name that is a child element of payee:

name = et.SubElement(payee, 'name')

We also need to assign an element value to the name element:

name.text = 'John Smith'

It’s not required for this example, but if you would have to add an attribute, say, type, with value fullName to the name element, you could do so like this:

name.set('type', 'fullName')

Creating the entire XML request body for our API call is a matter of repeating the above statements in the right order, with the right values:

def create_xml_body_using_elementtree():
    payee = et.Element('payee')
    name = et.SubElement(payee, 'name')
    name.text = 'John Smith'
    address = et.SubElement(payee, 'address')
    street = et.SubElement(address, 'street')
    street.text = 'My street'
    city = et.SubElement(address, 'city')
    city.text = 'My city'
    state = et.SubElement(address, 'state')
    state.text = 'My state'
    zip_code = et.SubElement(address, 'zipCode')
    zip_code.text = '90210'
    phone_number = et.SubElement(payee, 'phoneNumber')
    phone_number.text = '0123456789'
    account_number = et.SubElement(payee, 'accountNumber')
    account_number.text = '12345'
    return et.tostring(payee)

Note that we need to convert the element tree into a string before we can use it with the requests library. We can do this using the tostring() method.

While the approach using ElementTree might look a little more cumbersome than simply specifying our XML as a string, it gives us the option of creating more complex and flexible XML documents by creating loops to repeat XML blocks, working with data sources that are transformed into XML, and so on. I myself don’t really prefer one approach over the other, but I think it’s good to be aware of both and choose the one that best fits your requirements.

If we want to use the XML created using ElementTree above as a request body, we can do that in exactly the same way as when we used a string containing the XML:

def test_send_xml_body_from_elementtree_check_status_code_and_content_type():
    response = requests.post(
        headers={"Content-Type": "application/xml"},
    assert response.status_code == 200
    assert response.headers["Content-Type"] == "application/xml"

Parsing and working with XML response bodies
Now that we have covered creating XML request bodies, let’s see what we can do with XML responses. By far the most powerful way to create specific assertions is to convert the XML response body into an ElementTree and then asserting on its properties.

As an example, we’re going to perform an HTTP GET call to


which returns details of the account with ID 12345. If we want to assert, for example, that the root node of the XML response is named account, and that it has neither any attributes nor a text value, we can do this as follows:

def test_check_root_of_xml_response():
    response = requests.get("http://parabank.parasoft.com/parabank/services/bank/accounts/12345")
    response_body_as_xml = et.fromstring(response.content)
    xml_tree = et.ElementTree(response_body_as_xml)
    root = xml_tree.getroot()
    assert root.tag == "account"
    assert len(root.attrib) == 0
    assert root.text is None

Note that we first have to convert the XML response body to an object of type Element using the fromstring() method, then create an ElementTree out of that using the ElementTree() constructor, which takes an Element as its argument.

If we’re interested in the text value of a specific subelement of the XML response, for example customerId which contains the ID of the customer to whom this account belongs, we can do that by finding it in the ElementTree using the find() method, then write an assertion on the text property of the found element:

def test_check_specific_element_of_xml_response():
    response = requests.get("http://parabank.parasoft.com/parabank/services/bank/accounts/12345")
    response_body_as_xml = et.fromstring(response.content)
    xml_tree = et.ElementTree(response_body_as_xml)
    first_name = xml_tree.find("customerId")
    assert first_name.text == "12212"

It’s good to know that the find() method returns the first occurrence of a specific element. If we want to return all elements that match a specific name, we need to use findall() instead:

def test_use_xpath_for_more_sophisticated_checks():
    response = requests.get("http://parabank.parasoft.com/parabank/services/bank/customers/12212/accounts")
    response_body_as_xml = et.fromstring(response.content)
    xml_tree = et.ElementTree(response_body_as_xml)
    savings_accounts = xml_tree.findall(".//account/type[.='SAVINGS']")
    assert len(savings_accounts) > 1

As you can see, next to passing element names directly, we can also use XPath expressions to perform more sophisticated selections. The expression


in the example above selects all occurrences of the type element (a child element of account) that have SAVINGS as their element value.

Using the examples for yourself
The code examples I have used in this blog post can be found on my GitHub page. If you download the project and (given you have installed Python properly) run

 pip install -r requirements.txt

from the root of the python-requests project to install the required libraries, you should be able to run the tests for yourself. See you next time!