DEV Community: Ahsan Bilal

Key Hacks for Testers: Unleashing the Power of the Network Tab in Your Browser

Ahsan Bilal — Fri, 19 May 2023 20:00:30 +0000

Introduction

As a tester, your role is crucial in ensuring the quality and functionality of web applications. One indispensable tool at your disposal is the Network tab in your browser’s developer tools. This powerful feature enables you to monitor and manipulate network requests, analyse performance, and detect potential issues. In this article, we will explore some key hacks for testers, empowering you to make the most of the Network tab and enhance your testing capabilities.

Understanding the Network Tab

The Network tab is a part of the developer tools provided by modern web browsers. To access it, simply right-click anywhere on a webpage, select “Inspect” or “Inspect Element,” and navigate to the “Network” tab.

This tab displays all the network requests made by the web page, including HTTP requests, responses, and associated details.

Monitoring Network Requests & Analysing Performance

By monitoring network requests, you gain valuable insights into the behaviour and performance of a web application. The Network tab displays various columns, such as URL, status code, size, and timing, enabling you to track individual requests. You can filter requests based on specific criteria, such as file type or response code, to focus on relevant data.

The Network tab also allows you to evaluate the performance of web pages and identify potential bottlenecks. By examining the timing information, you can pinpoint requests that contribute to slow loading times. Look for requests with long “Waiting” or “Content Download” times, which may indicate areas for optimisation. Additionally, the waterfall view provides a visual representation of request timings, aiding in performance analysis.

Inspecting Request and Response Headers

Request and response headers contain vital information exchanged between the client and the server. In the Network tab, you can inspect headers to understand how requests are made and how servers respond. This is particularly useful when testing APIs or troubleshooting authentication issues. Look for specific headers, such as “Authorisation” or “Content-Type,” to ensure correct configurations.

Manipulating Requests

The Network tab empowers testers to manipulate network requests, enabling them to simulate different scenarios and edge cases. For example, you can modify request headers, such as User-Agent or Referer, to mimic different user agents or referrers (also called user-agent spoofing). You can also modify request payloads or parameters to test specific conditions or validate input sanitisation. These manipulations help uncover vulnerabilities and assess the resilience of the application.

Capturing Network Traffic

In certain testing scenarios, capturing network traffic becomes essential for thorough analysis. The Network tab allows you to save all requests and responses as a HAR (HTTP Archive) file. This file contains a detailed record of the network activity, including headers, timings, and content. By capturing network traffic, you can reproduce issues, share findings with developers, or preserve evidence for further investigation.

Simulating Network Conditions

Testing under different network conditions is crucial to ensure optimal performance across various environments. The Network tab provides built-in options to simulate network conditions, such as throttling the network speed or introducing latency. By mimicking slow or unreliable network connections, you can observe how the application behaves in real-world scenarios and address any performance issues accordingly.

Leveraging Performance Analysis Tools

To initiate performance recording, simply click the “Measure page load” button in DevTools. The page will reload, and the recording will automatically stop a few seconds after the page has finished loading.

Among the standout functionalities of Performance Insights, the playback feature stands out as one of the most remarkable. It enables you to not only replay the entire performance recording but also delve into specific moments within the record by zooming in.

What amplifies its effectiveness further is its seamless alignment with the tasks being carried out by the browser in real-time, such as network requests and rendering. This visual correlation enhances the overall power and usability of the feature.

Conclusion

The Network tab in your browser’s developer tools is an essential tool for testers, offering a wide range of features to analyse, monitor, and manipulate network requests. By mastering its capabilities and implementing the hacks discussed in this article, you can enhance your testing skills, uncover hidden issues, and contribute to the overall quality of web applications.

By embracing the power of the Network tab and continuously acquiring new skills, you become an invaluable asset in ensuring the quality and functionality of web applications. Unlock a world of possibilities for comprehensive and effective testing. Happy testing!

If you liked this, click ❤ so other people will also notice here.

Mastering Advanced Cypress.io Test Automation [Part 4/4]: Writing Custom Functions

Ahsan Bilal — Fri, 12 May 2023 01:47:05 +0000

By the end of this part, you’ll be proficient in writing custom functions for your Cypress.io test suite, paving the way to advanced test automation. So, let’s get started!

Understanding Custom Functions in Cypress.io

Before we dive into the code, let’s first understand what custom functions are in the context of Cypress.io.

While Cypress.io provides many built-in commands to interact with web elements, there may be situations where you need to perform more complex actions or write custom assertions. Fortunately, Cypress.io allows you to create your own custom functions that extend the functionality of Cypress.io. They can be used to perform specific tasks that are not natively supported by Cypress.io, or to simplify the code and make it more readable.

Writing a Custom Function in Cypress.io [Example-1]

Now that we understand what custom functions are, let’s move on to writing one. In this example, we’ll create a custom function to generate random usernames.

function generateRandomUsername() {
  let text = "";
  let possible = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

  for (let i = 0; i < 8; i++) {
    text += possible.charAt(Math.floor(Math.random() * possible.length));
  }

  return "user_" + text;
}

Let’s break down the code above. The generateRandomUsername function takes no parameters and returns a string value. It starts by declaring two variables text and possible.

text is initially an empty string, and possible contains all the possible characters that can be used to generate the random string.

Next, a for loop is used to iterate 8 times, and in each iteration, a random character is selected from the possible string using the Math.random() function. The selected character is then appended to the text string.

Finally, the function returns a string value by concatenating the text string with the prefix “user_”.

Using the Custom Function [Example-1] in a Test Case

Now that we have our custom function, let’s use it in a test case. In this example, we’ll use the custom function to generate a random username and fill it in a registration form.

it('registers a new user with a random username', () => {
  const username = generateRandomUsername();

  cy.visit('https://example.com/register')
  cy.get('#username').type(username)
  cy.get('#email').type('test@example.com')
  cy.get('#password').type('password123')
  cy.get('#submit').click()

  cy.contains('Registration successful!')
})

The test case above starts by generating a random username using our custom function generateRandomUsername(). We then visit the registration page and use the cy.get() command to select the #username, #email, #password, and #submit elements on the page. We fill in the form fields with our test data and click the submit button.

Finally, we assert that the registration was successful by checking for the presence of the success message.

Writing a Custom Function in Cypress.io [Example-2]

Let’s say you need to check that a particular element is visible on the page and has a certain size. You could write a custom function that encapsulates this logic:

Cypress.Commands.add('assertElementIsVisibleAndHasSize', (selector, width, height) => {
  cy.get(selector).should('be.visible').and(($el) => {
    expect($el.width()).to.equal(width)
    expect($el.height()).to.equal(height)
  })
})

Here, we’re defining a custom command using the Cypress.Commands.add() method. Our command takes three parameters: the selector for the element, the expected width, and the expected height. We then use the cy.get() command to select the element and chain the .should() method to check that it is visible. Finally, we use the .and() method to perform additional assertions on the element’s width and height.

Now, you can use this custom command in your tests just like any other Cypress.io command:

it('Checks the size of a visible element', () => {
  cy.visit('https://www.example.com')
  cy.assertElementIsVisibleAndHasSize('.my-element', 100, 200)
})

Summary: Here we’ve seen how to write custom functions in Cypress.io to extend the functionality of the framework and tackle complex test automation scenarios. We’ve provided a detailed explanation of each line of code, how it differs from basic test-case examples, and how to overcome common complications. By using custom functions, you can make your test code more readable, maintainable, and reusable. Custom functions can help you simplify complex test cases, handle dynamic data, and reduce code duplication.

If you liked this, click ❤ so other people will also notice here.

Real-world Examples

While the examples we’ve provided in this series of advanced and complicated topics are useful for learning how to handle iframes, network stubbing, promise resolving, and custom functions, they are somewhat contrived. To truly master these techniques, it’s important to see how they can be applied in real-world scenarios.

For example, let’s say you’re testing an e-commerce website that uses iframes to display product information from a third-party vendor. You might need to test that the correct product information is being displayed in the iframe, and that users can interact with the product options and add the product to their cart.

Similarly, let’s say you’re testing a social media application that relies heavily on network requests to display user content. You might need to use network stubbing to simulate slow network connections or error responses, and test how the application handles these situations.

Finally, let’s say you’re testing a financial application that requires complex interactions with web elements. You might need to write custom functions to perform calculations or validate that certain financial data is being displayed correctly.

By incorporating real-world scenarios into your test automation strategy, you can ensure that your tests are relevant and effective at catching real-world issues. Keep in mind that these advanced techniques are just tools in your testing arsenal — the key is to use them wisely and strategically to achieve your testing goals.

Conclusive Remarks

In this series of topics, we’ve explored some advanced techniques for Cypress.io test automation, including handling iframes, network stubbing, promise resolving, and custom functions. We’ve provided code examples and explained each concept in detail, and we’ve also highlighted the importance of incorporating real-world scenarios into your testing strategy.

By mastering these techniques, you’ll be able to write more efficient and effective automated tests, and catch bugs before they make it to production. With Cypress.io’s powerful testing capabilities and your newfound skills, you’ll be able to take your testing game to the next level. Happy testing!

Mastering Advanced Cypress.io Test Automation [Part 3/4]: Promise Resolving

Ahsan Bilal — Fri, 12 May 2023 01:37:27 +0000

With the techniques covered in this part, you’ll have a grasp on promise resolution in Cypress.io and be closer to mastering advanced test automation with Cypress. Let’s begin!

Promise-Resolving

JavaScript is an asynchronous language and often relies on promises to handle async operations. Cypress.io offers powerful tools for handling promises in tests. In this article, we will cover how to resolve promises in Cypress.io tests with an advanced-level example.

Promise-Resolving with Cypress.io: Promises are a fundamental part of modern JavaScript, and they enable asynchronous operations in a non-blocking manner. In Cypress.io, we can use the .then() method to resolve promises. However, sometimes we may encounter situations where we need to resolve promises before executing further test cases.

Consider a scenario where we need to log in to a website and then perform some actions on the dashboard. Cypress.io offers powerful tools for handling such situations.

Here’s an example code:

describe('Promise-Resolving', () => {
  it('Logs in and performs actions on dashboard', () => {
    cy.visit('https://example.com')
    cy.get('#username').type('testuser')
    cy.get('#password').type('testpassword')
    cy.get('#login-button').click()

    cy.url().then((url) => {
      if (url.includes('/dashboard')) {
        cy.get('#dashboard-actions').click()
        cy.get('#dashboard-action-1').click()
        cy.get('#dashboard-action-2').click()
      }
      else {
        cy.log('User is not logged in')
      }
    })
  })
})

In the code above, we first visit the website and enter the login credentials. After clicking on the login button, we resolve the promise by using the .then() method. We then check if the user is redirected to the dashboard page. If yes, we perform some actions on the dashboard. If not, we log a message saying that the user is not logged in.

Here is a step-by-step breakdown of the code example:

We start by visiting the website using the cy.visit() method.
We then use the cy.get() method to locate the username and password fields and enter the login credentials.
We click on the login button using the cy.get() method and the .click() method.
After clicking on the login button, we use the cy.url() method to get the current URL and resolve the promise using the .then() method.
We then check if the URL includes ‘/dashboard’. If yes, we perform some actions on the dashboard using the cy.get() and .click() methods.
If the URL does not include ‘/dashboard’, we log a message saying that the user is not logged in.

Complications and Possible Solutions:

One common issue with resolving promises in Cypress.io tests is that it can lead to flaky tests. Flaky tests are tests that sometimes pass and sometimes fail without any obvious reason. This can happen when the promise resolution takes longer than expected, and the test fails because it times out. To avoid flaky tests, we can use the cy.wrap() method to wrap the promise and ensure that the test waits until the promise is resolved before proceeding.

it('Resolves promises using cy.wrap()', () => {
  // Promise that resolves after 2 seconds
  const promise = new Promise(resolve => {
    setTimeout(() => {
      resolve('Promise resolved!')
    }, 2000)
  })

  // Wrapping the promise with cy.wrap() ensures that the test waits for it to resolve
  cy.wrap(promise).should('equal', 'Promise resolved!')
})

In the example above;

We define a promise that resolves after 2 seconds using the setTimeout() method.
We then wrap the promise with the cy.wrap() method, which ensures that the test waits for the promise to resolve before proceeding.
We use the .should() method to assert that the resolved value of the promise is equal to ‘Promise resolved!’.

In this way, we can ensure that our tests wait for promises to resolve and avoid flakiness in our Cypress.io tests. But another complication is when we encounter nested promises. In such cases, we can use the Promise.all() method to resolve multiple promises at once.

it('Resolves nested promises using Promise.all()', () => {
  cy.visit('https://example.com')
  cy.get('#my-element').then(element => {
    // Perform an action that returns a promise
    const promise1 = element.click()
    // Perform another action that returns a promise
    const promise2 = cy.get('#my-other-element').click()
    // Use Promise.all() to wait for both promises to resolve
    Promise.all([promise1, promise2]).then(() => {
      // Assert that the expected behavior has occurred
      cy.get('#my-element').should('have.class', 'active')
      cy.get('#my-other-element').should('be.visible')
    })
  })
})

In this example, we’re visiting a website and then selecting an element with the ID #my-element. We're then performing two actions on this element that return promises: a .click() action and a cy.get() action to select another element. We're using Promise.all() to wait for both of these promises to resolve before asserting that the expected behaviour has occurred.

Here’s a step-by-step breakdown of what’s happening in this code:

We visit the website using cy.visit().
We select an element with the ID #my-element using cy.get().
We perform an action on this element that returns a promise by calling element.click(). We store this promise in a variable called promise1.
We perform another action that returns a promise by calling cy.get('#my-other-element').click(). We store this promise in a variable called promise2.
We use Promise.all() to wait for both promises to resolve by passing an array of promises as an argument. When both promises have resolved, the .then() callback is executed.
Inside the .then() callback, we assert that the expected behaviour has occurred by using cy.get() and .should() to check that the #my-element element has the class active and that the #my-other-element element is visible.

Using Promise.all() in this way ensures that all promises are resolved before the test continues, helping to prevent flaky tests caused by promise resolution taking longer than expected.

Summary: Handling promises in Cypress.io tests is a critical skill for test automation engineers. It enables us to write more robust tests and handle complex scenarios. In this article, we covered how to resolve promises in Cypress.io tests with an advanced-level example. We also discussed the complications and possible solutions to ensure reliable tests. With these techniques, you can create more robust and efficient tests that can handle complex async scenarios.

If you liked this, click ❤ so other people will also notice here.

Mastering Advanced Cypress.io Test Automation [Part 2/4]: Network Stubbing

Ahsan Bilal — Fri, 12 May 2023 01:25:10 +0000

With the examples covered in this part, you’ll gain a strong grasp of network stubbing in your Cypress.io test suite and be one step closer to mastering advanced Cypress.io test automation. So, let’s get started!

Network Stubbing

Another challenge in web application testing is dealing with network requests. In some cases, you may want to simulate network responses in your tests. For example, you might want to test how your application handles errors or slow network connections.

The cy.intercept() command is used to intercept specific network requests and provide custom responses. You can pass in the HTTP method, URL, and response object as arguments to the cy.intercept() command. The response object can include a fixture, which is a static JSON file that serves as a mock response.

Let’s take a look at some code examples to see how network stubbing works in Cypress.

Example 1: Simulating a Slow Network Connection

In this example, we’re intercepting a GET request to the URL https://api.example.com/users and responding with a fixture called “users.json”. We’re also using the cy.wait() command to simulate a slow network connection.

describe('Network Stubbing', () => {
  beforeEach(() => {
    cy.intercept('GET', 'https://api.example.com/users', {
      fixture: 'users.json'
    }).as('getUsers')
  })

  it('Visits a website that uses an external API', () => {
    cy.visit('https://www.example.com')
    cy.wait('@getUsers').then(({ response }) => {
      expect(response.statusCode).to.equal(200)
      expect(response.body).to.have.length(2)
      expect(response.body[0]).to.have.property('name', 'FirstName LastName')
    })
  })
})

Let’s break down the code step by step:

The describe function is used to group related tests together. In this case, we’re grouping tests related to network stubbing.
The beforeEach function is used to set up a mock server and define a route for the server to respond to using cy.intercept(). In this case, we’re intercepting a GET request to the URL https://api.example.com/users and responding with a fixture called “users.json”.
The test, it('Visits a website that uses an external API', ()=>{...}), visits a website and waits for the response from the mocked API route we defined earlier using cy.intercept(). Once the response is received, we use the .then() function to perform assertions on the response. In this case, we’re asserting that the response has a status code of 200, has a length of 2, and that the first user object has a name of ‘FirstName LastName’.

Example 2: Handling Dynamic Responses

In this example, we’re intercepting a dynamic API route and responding with user data. We’re using the .its() function to drill down into the response JSON and check that the data returned for the user with ID 1 matches our expected data.

it('Handles dynamic response', () => {
  // Intercept the dynamic API route and respond with user data
  cy.intercept('GET', '/api/users/*', req => {
    req.reply({
      statusCode: 200,
      body: {
        id: req.path.split('/')[3],
        name: 'FirstName LastName',
        email: 'fullname@example.com',
        age: 30
      }
    })
  }).as('dynamicApiRoute')
  // Visit a website and wait for response from mocked API route
  cy.visit('/')
  cy.wait('@dynamicApiRoute')
  // Assert that the response contains the correct user data
  cy.get('@dynamicApiRoute')
    .its('response.body')
    .should('deep.equal', {
      id: '1',
      name: 'FirstName LastName',
      email: 'fullname@example.com',
      age: 30
    })
})

Here is a step-by-step breakdown of the code example:

We start with the test case description: “Handles dynamic response”.
We then use the cy.intercept() method to intercept a dynamic API route. The route is defined with a wildcard * in the URL path, which means that any URL that matches the pattern /api/users/* will be intercepted.
Inside the intercept method, we use the req.reply() method to respond with user data. The req object contains information about the intercepted request, including the URL path. We extract the user ID from the URL path using the .split() method and add it to the response body.
We then visit a website using the cy.visit() method and wait for the response from the mocked API route using the cy.wait() method. Note that we haven't defined an alias for this route yet.
We define an alias for the intercepted route using the .as() method. We use the name dynamicApiRoute as the alias.
We then assert that the response contains the correct user data. We use the cy.get('@dynamicApiRoute') method to get the response for the intercepted route using the alias. We then use the .its() method to access the response.body property of the response. Finally, we use the .should() method with the deep.equal assertion to compare the response body with the expected user data.

Example 3: Handling Errors

In this example, we’re intercepting an API route that returns a 500 server error using cy.intercept(). Once again, we’re visiting the website and waiting for the response from the mocked API route. We’re then checking that the response contains the expected error message.

it('Handles errors', () => {
  // Intercept an API route that returns a 500 server error
  cy.intercept('GET', '/api/error', {
    statusCode: 500,
    body: 'Internal Server Error'
  }).as('errorRoute')

  // Visit the website and wait for response from mocked API route
  cy.visit('/')
  cy.wait('@errorRoute').then(({ response }) => {
    expect(response.statusCode).to.equal(500)
    expect(response.body).to.equal('Internal Server Error')
  })
})

The test first intercepts the API route that returns a 500 server error using cy.intercept(). The method takes three arguments: the HTTP method, the URL to intercept, and an object containing the response to return. In this case, we're returning a response with a status code of 500 and a body of "Internal Server Error". We also give this intercept a unique name using .as('errorRoute') so that we can reference it later.

Next, we visit the website using cy.visit() and wait for the response from the mocked API route using cy.wait('@errorRoute'). Once the response is returned, we can access it in the callback function using destructuring to get the response object.

Finally, we use expect() to check that the response contains the expected error message. We check the statusCode property of the response to ensure that it is 500, and we check the body property of the response to ensure that it matches the expected "Internal Server Error" message.

By intercepting and mocking API routes in this way, we can simulate different responses from the server and ensure that our frontend code handles them correctly. This makes it easier to test our application and catch errors before they make it to production.

Summary: Overall, these examples demonstrates how to use network stubbing in Cypress.io to mock API responses and control the data returned by the API. By using network stubbing, we can ensure that our tests are predictable and repeatable, even when testing applications that rely on external APIs.

If you liked this, click ❤ so other people will also notice here.

Mastering Advanced Cypress.io Test Automation [Part 1/4]: Dealing with Iframes

Ahsan Bilal — Fri, 12 May 2023 01:13:06 +0000

Welcome to the first instalment of our series on mastering advanced Cypress.io test automation! In this series, we’ll be diving deep into some of the most complex concepts and techniques for writing efficient and effective automated tests with Cypress.io.

In this series of articles, we will delve into complex concepts such as handling iframes, network stubbing, and resolving promises with Cypress.io. Additionally, we will provide you with valuable insights on how to create custom functions to address the unique testing challenges that Cypress.io does not cover directly. So, fasten your seatbelts and get ready to elevate your Cypress.io proficiency!

In this first part, we’ll be focusing on one of the most challenging aspects of test automation: dealing with iframes. As you may already know, iframes can present unique challenges for automated testing, since they essentially embed one website inside another. We’ll explore some strategies and techniques for handling iframes in your Cypress.io tests, including how to locate and interact with elements inside iframes, how to assert on iframe content, and how to handle cross-domain iframes.

By the end of this part, you’ll have a solid understanding of how to tackle iframes in your Cypress.io test suite, and you’ll be well on your way to mastering advanced Cypress.io test automation. So, let’s get started!

Dealing with Content within Iframes

When testing web applications, it’s not uncommon to come across iframes, which are HTML elements used to embed another document within the current HTML document. Testing content within iframes can be a bit more complicated than testing regular HTML elements, but Cypress.io provides us with the tools we need to tackle this challenge.

Real-World Example

Suppose you are testing a web page that has a chatbot integrated into an iframe. To test the chatbot functionality, you need to interact with the iframe’s elements. However, because the iframe’s elements are technically part of a separate document, you cannot access them directly from the parent document using the Cypress commands. Instead, you need to switch the context of your test to the iframe document in order to interact with its elements. You can do this by using the cy.get() command to select the iframe element based on its attributes, using the .then() method to access the contents of the iframe using the $iframe.contents() method, and finally, using the cy.wrap() command to wrap the form element and save it to an alias @form that you can reference later in your test.

Understanding the Challenge

One of the challenges of testing content within iframes is that the elements within the iframe are technically part of a separate document. This means that we cannot access them directly from the parent document using the Cypress commands. Instead, we need to switch the context of our test to the iframe document in order to interact with its elements.

The Code Example

To illustrate how to deal with content within iframes in Cypress.io, let’s use the example of a web page that contains an iframe with a form element. Our goal is to fill out the form and submit it.

First, we need to identify the iframe element using the cy.get() command and save it to a variable. We'll use the iframe() command to get the content of the iframe:

cy.get('iframe[name="my-iframe"]').then(($iframe) => {
  const iframeContents = $iframe.contents()
  cy.wrap(iframeContents.find('form')).as('form')
})

Here, we’re using the cy.get() command to select the iframe element based on its name attribute. We then use the .then() method to access the contents of the iframe using the $iframe.contents() method, which returns the document object of the iframe.

Next, we use the cy.wrap() command to wrap the form element and save it to an alias @form that we can reference later in our test.

Now that we have access to the iframe document and the form element, we can interact with the form fields and submit the form as we would with any other form element. For example, let’s fill out the form and submit it:

cy.get('@form').find('[name="name"]').type('FirstName LastName')
cy.get('@form').find('[name="email"]').type('firstname.lastname@example.com')
cy.get('@form').find('button[type="submit"]').click()

Here, we’re using the cy.get('@form') command to reference the form element that we saved to the @form alias earlier. We then use the .find() method to select the form fields by their name attributes and fill them out using the .type() command. Finally, we use the .click() command to submit the form.

Enough for now.

In subsequent parts of this article, I’ll talk about Network Interception, Promise Resolving, and Writing Custom Functions.

Up Next: Part 2, Part 3, Part 4

If you liked this, click ❤ so other people will also notice here.