REST has been the de facto standard for APIs for a while now, replacing the relatively cumbersome and XML-only SOAP-based APIs with an architecture that is more flexible, lightweight and easier to develop. However, REST is not without limits of its own. With pure REST, if you need to gather and combine data from multiple endpoints or entities, the API consumer typically needs to invoke multiple endpoints, collect the data from each of these endpoints and combine and filter that data into something useful.

Enter GraphQL. GraphQL tries to solve this problem by exposing all data through a single endpoint and allow the API consumer to write queries that retrieve the exact data required at any given moment, all with a single API call. The API consumer composes the query that should retrieve the data required, POSTs that query to the GraphQL API provider, which, if all goes well, then returns the requested data as a JSON document in the response.

Of course, when you’re developing GraphQL APIs, at some points you will want to write tests for them, too (right?). Developers and test automation engineers working with REST APIs and Java will probably have heard of or even worked with REST Assured, but can we use that for testing GraphQL APIs, too? Let’s find out.

Before we start to write some tests, we’ll need a GraphQL API to write tests for first. In this article, we’ll use the SpaceX GraphQL API, which exposes data about the SpaceX company and their space missions, launches and more. The API can be found at https://api.spacex.land/graphql/ and comes with a GraphiQL explorer allowing you to play around with the API and retrieve some SpaceX data yourself.

Let’s start with a basic example: retrieving some data about the SpaceX company itself, more precisely the company name, as well as the name of its CEO and COO. The GraphQL query required to retrieve this data looks like this:

To submit this query to the SpaceX GraphQL endpoint, we’ll need to create a JSON payload with a single element ‘query’ with our query as its value. I prefer to let REST Assured take care of creating the JSON payload instead of constructing it myself, so I’ve created a simple POJO that represents a GraphQL query, which can be serialized to JSON by REST Assured:

This POJO has two properties, ‘query’ and ‘variables’, and I’ve used the Lombok, and more specifically its @Data annotation, to create getters and setters for both properties. The ‘query’ property will hold our GraphQL query. We’ll talk about the ‘variables’ in a bit, let’s first see how we can use this class to send our first GraphQL query.

Now that we have set up a POJO that represents our payload, all we need to do in our test is create a new instance of it, fill the ‘query’ property with our GraphQL query and POST that to the SpaceX GraphQL endpoint. Since the response of a GraphQL API is plain JSON, we can assert on data returned by the API in the exact same manner with REST Assured as with ‘regular’ REST APIs. You can learn more about that in this free Test Automation University course: https://testautomationu.applitools.com/automating-your-api-tests-with-rest-assured.

Assuming we want to check that the API returns an HTTP status code 200 and that the data reflects that Elon Musk is the CEO of SpaceX, this is what a first GraphQL API test with REST Assured looks like:

Excellent! We have successfully written and run our first GraphQL API test with REST Assured. However, the typical query you will want to execute is probably not so static. GraphQL queries support variables, so let’s take a look at how we can incorporate those in our tests, too.

Say that for our next test, we want to query the launches performed by SpaceX, and retrieve the names of the missions these were associated with, but limit the number of results to 10. The GraphQL query to do that looks like this:

To make the actual limit a variable (maybe we’re only interested in 5 results another time we run this query), we’ll have to add a variable to the query:

and pass the value of the ‘limit’ variable separately:

This is where the ‘variables’ property in the GraphQLQuery class we created earlier comes into play. If we want to execute this parameterized GraphQL query with REST Assured, we’ll need to pass both the (parameterized) query itself, as well as its variables to the SpaceX API. We can pass the query itself as a string, just like we did in the first example. For the parameters, we can choose between two different approaches. We can:

1. create a new POJO that holds the value for the ‘$limit’ variable, just like we did for the query itself, or we can
2. dynamically add variables for our query using a JSONObject

In the first approach, our POJO for the $limit variable may look like this:

We can then pass that as part of our query using REST Assured like this, and assert on the mission name of the first launch like this:

If you’d prefer to use a JSONObject for the query variables instead, this is what that might look like:

Don’t forget to use .toString() on the JSONObject holding the variables before adding them to your query, otherwise the serialization mechanism has no idea how to create a JSON string from the JSONObject and no variables will be passed!

So, which approach is better? In my opinion, as with so many different things in test automation (and life in general): it depends. If you prefer the flexibility of adding variable names and their values ‘on the go’ in your tests, I’d recommend using a JSONObject and simply putting in there what you need. If you want to be a little more strict, and you don’t have a lot of different sets of variables to deal with, creating POJOs for them might be a good idea. As you’ve seen, both will work fine with REST Assured.

Finally, let’s take a look at a different type of query. So far, we have only retrieved data from the SpaceX GraphQL API, but it’s also possible to send data to it, for example to create your own user. Instead of a ‘query’ operation, you’ll need to perform a ‘mutation’ operation to do that:

This mutation inserts a new user, represented by an ‘id’ (a UUID) and containing a name (string) and a rocket (also a string). Because a user is probably an entity that is used more often in the test code (as well as in the application code, probably), I’ve chosen to use a POJO to create a user entity:

We can then use this POJO to create and send a new user to the SpaceX GraphQL API in our test, and check that the data returned in the response is the same as the data we have sent:

As you have seen in this article, with a couple of small steps, it is possible to use REST Assured not only to write tests for pure REST APIs, but also for GraphQL-based APIs. All code samples shown in this article can be found on GitHub for you to run and play around with.

The post Writing Tests for GraphQL APIs using REST Assured appeared first on Automated Visual Testing | Applitools.

Those looking to break into the test automation field have difficulty doing so because of lack of experience. One way to gain experience is, of course, to study and practice on your own. But how do you demonstrate your newfound knowledge to employers?

Other professionals, such as front-end developers, create portfolios to highlight their skills, and you can do the same as automation engineers!

Here are 10 projects for your test automation portfolio that will help you stand out among the competition.

1. Web browser automation

Web automation is by far the most common and sought-after form of test automation. If you’re looking to break into test automation, this is an absolute must-have for your portfolio.

Be sure to go beyond a basic login flow. Instead, show full scenarios that require your code to interact with multiple pages.

This project should demonstrate your ability to find element locators and interact with various types of elements such as dropdown menus, checkboxes, text fields, buttons, links, alerts, file upload widgets, and frames.

Also, be sure you’re writing clean test code and utilizing design patterns such as the Page Object Model or the Screenplay Pattern.

Sites to practice against:

• The-internet (Heroku)
• ToolsQA
• Formy
• ParaBank (login is john/demo)
• OpenCart

2. Mobile automation

The demand for mobile test automation engineers has increased over the years as the popularity of mobile apps has soared. Having experience here can certainly work in your favor.

Your portfolio should demonstrate automated testing against both iOS and Android apps. Using Appium to create one project that works for both iOS and Android would be great. Using tools such as Apple’s XCUITest or Google’s Espresso is good as well. But if you go this route, I recommend doing at least two projects (one of each), since each supports only one mobile operating system.

No matter which framework you use, you’ll want to demonstrate the same element interactions as you did in your web automation project, but also mobile-specific gestures such as swiping and pinching.

Apps to practice with; download any of these to use in your project:

• Android apps (you’ll need to fill out the CAPTCHA form before you can access the apps)
• iOS apps

3. Visual automation

After making your web and mobile projects, fork them and add visual testing capabilities to them. You’ll quickly see just how much your tests are missing because they weren’t enabled to verify the appearance of your app.

Visual testing is a skill being listed on a number of job postings, and having this skill will really help you shine against the competition.

4. API automation

With the rise of microservices, IoT applications, and public-facing APIs, the demand for automation engineers who know how to test APIs has become substantial. So definitely add an API testing project to your portfolio. (Here’s a free class on how to test APIs to get you started.)

Within this project, be sure to demonstrate a variety of API methods, with GET and POST as a minimum. Use APIs that require parameters or request bodies, and also return complex responses with multiple objects and arrays.

For bonus points, use advanced verification techniques such as deserialization or approval testing. Also, demonstrating how to mock API responses would be a nice bonus.

APIs to practice against:

• Swagger Petstore
• ParaBank
• Restful booker
• Zippopotam.us

5. BDD specification automation

Many teams are practicing behavior-driven development (BDD) and automating tests based on the specifications produced. You’ll want to demonstrate your experience with this and how you can jump in and hit the ground running.

For this portfolio project, be sure to not only show the mapping between feature files and step definitions, but also demonstrate how to share state between steps via dependency injection.

Also, be extremely careful when writing your feature files. Long, verbose feature files will hurt your portfolio more than help. Make the effort to write good, concise Gherkin.

6. Data-driven automation

Your practice projects may use only a small amount of test data, so it’s easy to store that data inside the source code. However, on production development teams, you’ll have hundreds or even thousands of automated tests. To keep up with all this data, many teams adopt a data-driven testing approach.

I recommend adding this to at least one of your projects to demonstrate your ability to programmatically read data from an external source, such as a spreadsheet file.

7. Database usage

Speaking of being able to access data from external sources, it’s a good idea to add a project that interacts with a database. I recommend writing queries within your code to both read and write from a database, and use this within the context of a test.

For example, you can read from the database to gather the expected results of a search query. Or you can write to a database to place your application in a prerequisite state before proceeding to test.

8. Multiple languages and libraries

Writing all of your portfolio projects in one programming language is okay; however, automation engineers often need to dabble in multiple languages.

To make yourself more marketable, try using a different language for a few of your projects.

Also switch it up a bit and try a few other automation libraries as well as assertion libraries. For example, maybe do a project with Selenium WebDriver in Java and JUnit, and another project with Cypress in JavaScript and Mocha.

I know this sounds daunting, but you’ll find that some of the architecture and design patterns in test automation are universal. This exercise will really solidify your understanding of automation principles in general.

9. Accessibility automation

Automating accessibility testing has always been needed but recently has become extremely important for companies. There have been legal battles where companies have been sued because their websites were not accessible to those with disabilities.

Demonstrating that you are able to do test automation for accessibility will give you a great advantage when applying for jobs.

You can use the same sites/apps you used for your web and mobile projects to demonstrate accessibility testing.

10. Performance testing

Last but not least, you should consider adding a performance testing project to your portfolio.

Nonfunctional testing such as performance is a niche skill that many automation engineers do not have. Adding this to your portfolio will help you be perceived as a unicorn who really stands out from the crowd.

Presenting the Portfolio

GitHub

Be sure to put all of your projects on GitHub so employers can easily access and review your code. However, be careful to hide secret keys. This will give you bonus points, since it shows another level of maturity.

Website

Create a website that highlights each of your portfolio projects. You don’t have to build the website yourself; you can use common CMS systems such as WordPress to allow you to quickly get your portfolio up and visible.

Each project highlight should include a paragraph or bullet points explaining what you’ve done in the project and the tools and programming language used.

Resume

Include a link to your portfolio on your resume, and feel free to list your portfolio projects under the “Experience” section of your resume.

While this is not traditional work experience, it shows that you are self-driven, passionate, and competent to break into the test automation field.

Interview

During your interviews, be sure to mention all of the projects you have worked on. Draw from your experiences with building the projects to be able to answer the questions. Also brush up on other concepts around testing and development that may come up during the interview.

Good luck!

The original version of this post can be found at TechBeacon.com.

Header Photo by Shahadat Rahman on Unsplash

The post 10 Portfolio Projects for Aspiring Automation Engineers appeared first on Automated Visual Testing | Applitools.