Cypress API Testing Makes No Sense

This time, it is not Cypress’ fault. An example of how low fake ‘automated testers’ can get.

According to Cypress’ home page, Cypress is a browser-driving automation tool.

Image credit: Code horror from “Code Complete” book.

By the way, the so-called “Fast”, “Easy”, and “Reliable” are all false claims. That’s not surprising though, as Cypress is a commercial tool. The free Selenium WebDriver (W3C standard) is much better than Cypress in every aspect. Please check out my articles: 

• Why Cypress Sucks for Real Test Automation?

• Why Cypress Sucks for Real Test Automation? (Part 2: Limitations)

• Cypress vs Selenium WebDriver Comparison by Example

Every Cypress automated tester I have met (since 2019) is a fake. No exceptions! For some testers who disagree, check out the objective criteria in the Definition of End-to-End Test Automation Success. 

A ridiculous trend to use Cypress as an API Testing tool

Before 2021, fake automated testers, instead of acknowledging their incompetence or Cypress is a wrong choice, used usual excuses such as:

• test data changed
  (wrong, test data is a part of the test script)

• the application changed
  (of course, it will change, every IT people shall be aware of that)

Some honest ones would acknowledge the limitation of Cypress (after all, it was listed on Cypress’s website), and switch to Playwright, another bad choice (slightly better than Cypress, but still wrong!) 

Since 2021, I have heard of (or read articles on) using Cypress for API Testing. That’s crazy! Cypress is a browser-driving automation tool, according to its definition. 

I understand the why, though. It is a cunning trick. As Cypress test automation attempts failed everywhere (only good for demonstrations), these fakers came up with ‘better’ excuses. 

• Real end-to-end (via GUI) testing is not reliable
  Wrong. The nature of Web (GUI) Test Automation has not changed over 20 years. Why did you start Cypress with browser testing?
  By the way, I have been successfully implementing real end-to-end (via GUI) web test automation using raw Selenium WebDriver (see some examples here). It is a matter of capability. 

• We can do end-to-end API Testing, still using Cypress.
  So that the choice of Cypress wasn’t totally bad and embarrassing.

Often, they got away with those low-level excuses. Why? The managers and senior tech leads were already on board with Cypress’ embarrassments.

Using Cypress for API Testing is Ridiculous!

Cypress scripts are in JavaScript, a programming language. Most programming languages can invoke API service, therefore, for testing purposes. In other words, you do NOT need Cypress for API testing, one HTTP library will do. Then, it is just API Testing in JS.

Some desperate “Cypress testers” would argue “Cypress offers better syntax and is easier, compared to other JS HTTP libraries”. Really, I don’t see that, at most, just personal preferences. Also, don’t forget Cypress is not free!

Will there fake automated testers succeed in API testing with Cypress? No!

Let’s look at the facts:

• Those fake automated testers could create a few Cypress web tests.

• But unable to make the automated tests useful to the team, i.e. unable to maintain and cope with the changes.

The same issue will repeat on so-called Cypress API testing, JS API testing really. 

They lacked real test automation engineers’ skills and mindset, also Continuous Testing. Therefore, when these JS API tests reach a certain size, despite the challenge being much less compared to GUI Test automation, they would not be able to handle that as well. 

However, they could hide the embarrassment well on API testing. There is no visible execution, therefore, other people notice less. I have to say, it is a quite cunny trick. 

Next, I will compare typical ‘Cypress API Tests’ and its equivalent API tests in the Ruby language. 

Cypress API Testing Example

To be fair, I will use a Cypress API Test example in this Circle CI article: Testing an API with Cypress.

There are three files: 

1. Configuration (cypress.json):

{
   "baseUrl": "http://todo-app-barkend.herokuapp.com/",
   "integrationFolder": "cypress/integration/api-tests"
}

2. Package setup (package.json)

"scripts": {
   "test": "cypress open"
 },

3. Cypress Test Script (todo.spec.js):

describe('TODO api testing', () => {
   let todoItem;
   it('fetches Todo items - GET', () => {
       cy.request('/todos/').as('todoRequest');
       cy.get('@todoRequest').then(todos => {
           expect(todos.status).to.eq(200);
           assert.isArray(todos.body, 'Todos Response is an array')
       });
   });

   it('deletes Todo items - DELETE', () => {
       cy.request('DELETE', `/todos/${todoItem}`).as('todoRequest');
       // deletes Todo item with id = 9
       cy.get('@todoRequest').then(todos => {
           expect(todos.status).to.eq(200);
           assert.isString(todos.body, 'todo deleted!')
       });
   });
 
   it('Adds Todo item - POST', () => {
       cy.request('POST', '/todos/', { task: "run tests" }).as('todoRequest');
       // adds new Todo item by defining Todo name
       cy.get('@todoRequest').then(todos => {
           expect(todos.status).to.eq(200);
           cy.wrap(todos.body).should('deep.include', {
               task: 'run tests',
               completed: false,
           });
       });
   });
});

The much simpler way in Ruby, with Rest-Client library

Below is the equivalent API test with Rest-Client, an HTTP and RESET client for Ruby. 

Just one file (todo_spec.rb)

require "rest-client"
describe "Cypress Equivalent, better and simpler in Ruby" do

  before(:all) do
    @base_url = "http://todo-app-barkend.herokuapp.com"
  end

  it "fetches Todo items - GET" do
    resp = RestClient.get(@base_url + "/todos")
    expect(resp.code).to eq(200)
    expect(JSON.parse(resp.body).class).to eq(Array)
  end

  it "Adds Todo item - POST" do
    payload = { task: "run tests" }
    resp = RestClient.post("#{@base_url}/todos", JSON.generate(payload), "Content-Type" => "xxxx/xxx+json")
    expect(resp.code).to eq(200)
  end

  it "deletes Todo items - DELETE" do
    resp = RestClient.delete("#{@base_url}/todos/37")
    expect(resp.code).to eq(200)
    expect(page_text).to include("todo deleted!")
  end
end

It is much simpler, and the syntax is easier for all team members (not just JS programmers), isn’t it? I have been doing API Testing (regardless of the coding language the app was developed in) this way since 2008. By the way, the Rest-Client library is optional, I could use the built-in Ruby networking library net/https to perform API testing. The HTTP libraries, such as Rest-Client and Httparty , just offer a slightly simpler syntax. 

For more API testing with Ruby, the best test scripting language, check out my book: 

• API Testing Recipes in Ruby

Why using a browser-UI testing tool for API testing is bad?

It prevents real end-to-end user testing. Let me explain with a metaphor. Suppose a country introduced a hyped aeroplane for air travel for the first time. For whatever reason (pilot’s capability or aeroplane’s technical limitations or faults), the aeroplane was used itas a car, driving on the road. If someone suggests a better airline or pilot training for air travel, the existing staff and management will tend to say NO. Sooner and later, the management will terminate the embarrassing aeroplane-as-car services but will be reluctant to introduce other aeroplanes, including proper ones, such as Boeing (in the context of proper web test automation, Selenium WebDriver).

If this country started with faster, cheaper and better travelling on the ground, there are far better options than selecting aeroplanes.

FAQ