Why Asserting request properties in Cypress? - Purpose & Use Cases

The Big Idea

What if you could catch hidden request errors before users even see them?

The Scenario

Imagine testing a web app where you must check if every network request sends the right data. You open the browser, watch the network tab, and try to remember if each request had the correct headers or body. This feels like watching a slow movie and guessing if the story is right.

The Problem

Manually checking requests is slow and tiring. You can easily miss mistakes because you have to watch many requests and remember details. It's like trying to catch raindrops with your hands--some slip away unnoticed. This causes bugs to sneak into the app and frustrates testers.

The Solution

Asserting request properties with Cypress lets you automatically check every detail of network requests during tests. You write simple commands that watch requests and confirm they have the right data. This saves time, avoids human error, and makes tests reliable and repeatable.

Before vs After

✗ Before

Open DevTools > Network tab > Watch requests > Manually check headers and body

✓ After

cy.intercept('POST', '/api/login').as('loginRequest')
cy.wait('@loginRequest').its('request.body').should('include', { username: 'user1' })

What It Enables

It enables fast, automatic checks that catch mistakes early, making your app stronger and your testing smarter.

Real Life Example

When testing a login form, you can assert that the request sends the correct username and password every time, so users won't face login errors caused by wrong data.

Key Takeaways

Manual request checks are slow and error-prone.

Asserting request properties automates and speeds up validation.

This leads to more reliable tests and better app quality.

Practice

1. What is the primary purpose of using cy.intercept in Cypress tests?

easy

A. To watch and control network requests during test execution

B. To create UI elements dynamically

C. To write CSS styles for the application

D. To generate random test data automatically

Solution

1. Step 1: Understand cy.intercept role

   cy.intercept is used to monitor or stub network requests in Cypress tests.

2. Step 2: Identify correct purpose

   It helps watch and control HTTP requests, not UI or styling tasks.

3. Final Answer:

   To watch and control network requests during test execution -> Option A

4. Quick Check:

   cy.intercept = watch/control requests [OK]

Hint: Remember: intercept = watch network calls [OK]

Common Mistakes:

• Confusing intercept with UI manipulation
• Thinking intercept generates test data
• Mixing intercept with CSS styling

2. Which of the following is the correct syntax to assert that a request method is POST inside a cy.intercept callback?

easy

A. assert(req.method == 'POST')

B. assert.equal(req.method, 'GET')

C. expect(req.method).equals('post')

D. expect(req.method).to.equal('POST')

Solution

1. Step 1: Identify correct assertion syntax

   Cypress uses Chai assertions like expect(value).to.equal(expected).

2. Step 2: Match method and case sensitivity

   HTTP methods are uppercase strings, so 'POST' must be exact.

3. Final Answer:

   expect(req.method).to.equal('POST') -> Option D

4. Quick Check:

   expect().to.equal() with exact case [OK]

Hint: Use expect().to.equal() with exact method case [OK]

Common Mistakes:

• Using lowercase 'post' instead of 'POST'
• Using assert syntax instead of expect
• Checking wrong method like 'GET'

3. Given the following code snippet, what will the assertion check inside the intercept callback?

cy.intercept('POST', '/api/login', (req) => {
  expect(req.body).to.have.property('username', 'admin')
})

medium

A. The request headers must include username 'admin'

B. The request body must include a username property with value 'admin'

C. The response body must have username 'admin'

D. The request URL must contain 'username=admin'

Solution

1. Step 1: Analyze the assertion target

   The assertion checks req.body for a property named 'username' with value 'admin'.

2. Step 2: Understand request vs response and headers

   It does not check URL, response, or headers, only the request body.

3. Final Answer:

   The request body must include a username property with value 'admin' -> Option B

4. Quick Check:

   expect(req.body).to.have.property('username', 'admin') [OK]

Hint: Check if property is in req.body, not URL or headers [OK]

Common Mistakes:

• Confusing request body with URL query
• Checking response instead of request
• Looking at headers instead of body

4. Identify the error in this Cypress intercept assertion:

cy.intercept('GET', '/api/data', (req) => {
  expect(req.headers['Content-Type']).to.equal('application/json')
})

medium

A. The assertion syntax is incorrect

B. The method should be POST, not GET

C. Headers keys are case-insensitive; 'Content-Type' should be 'content-type'

D. The intercept callback must use res instead of req

Solution

1. Step 1: Check header key case sensitivity

   HTTP headers are case-insensitive, but Cypress normalizes header keys to lowercase in the req.headers object. The code uses 'Content-Type' which is incorrect; it should be 'content-type'.

2. Step 2: Validate other parts

   Method GET is valid, assertion syntax is correct, and req is proper for request interception.

3. Final Answer:

   Headers keys are case-insensitive; 'Content-Type' should be 'content-type' -> Option C

4. Quick Check:

   Cypress req.headers use lowercase keys [OK]

Hint: Cypress req.headers uses lowercase keys [OK]

Common Mistakes:

• Using wrong HTTP method
• Misusing response object instead of request
• Incorrect assertion syntax

5. You want to assert that a POST request to /api/submit contains a JSON body with a non-empty email property and a header Authorization starting with 'Bearer '. Which is the best way to write this assertion inside cy.intercept?

hard

A. cy.intercept('POST', '/api/submit', (req) => {
expect(req.body.email).to.be.a('string').and.not.be.empty
expect(req.headers.authorization).to.match(/^Bearer /)
})

B. cy.intercept('POST', '/api/submit', (req) => {
expect(req.body.email).to.exist
expect(req.headers.authorization).to.include('Bearer')
})

C. cy.intercept('POST', '/api/submit', (req) => {
assert.isString(req.body.email)
assert.include(req.headers.authorization, 'Bearer')
})

D. cy.intercept('POST', '/api/submit', (req) => {
expect(req.body.email).to.be.empty
expect(req.headers.authorization).to.equal('Bearer')
})

Solution

1. Step 1: Check email property assertion

   cy.intercept('POST', '/api/submit', (req) => { expect(req.body.email).to.be.a('string').and.not.be.empty expect(req.headers.authorization).to.match(/^Bearer /) }) asserts email is a non-empty string using to.be.a('string').and.not.be.empty, which is precise.

2. Step 2: Check Authorization header assertion

   cy.intercept('POST', '/api/submit', (req) => { expect(req.body.email).to.be.a('string').and.not.be.empty expect(req.headers.authorization).to.match(/^Bearer /) }) uses regex to.match(/^Bearer /) to ensure header starts with 'Bearer ', which is exact and case-sensitive.

3. Step 3: Compare other options

   cy.intercept('POST', '/api/submit', (req) => { expect(req.body.email).to.exist expect(req.headers.authorization).to.include('Bearer') }) uses correct lowercase header key, but .to.exist only checks existence (could be empty or falsy), and .to.include checks substring anywhere, not prefix.
   cy.intercept('POST', '/api/submit', (req) => { assert.isString(req.body.email) assert.include(req.headers.authorization, 'Bearer') }) uses non-standard assert style and misses non-empty check; include not prefix.
   cy.intercept('POST', '/api/submit', (req) => { expect(req.body.email).to.be.empty expect(req.headers.authorization).to.equal('Bearer') }) incorrectly expects empty email and exact 'Bearer' match only.

4. Final Answer:

   expect(req.body.email).to.be.a('string').and.not.be.empty
   expect(req.headers.authorization).to.match(/^Bearer /) -> Option A

5. Quick Check:

   Use precise type and regex assertions for properties [OK]

Hint: Use type checks and regex for precise property assertions [OK]

Common Mistakes:

• Ignoring case sensitivity in headers
• Checking only existence, not content
• Using wrong assertion style inconsistently