Cypress architecture (runs in browser) - Build an Automation Script

Verify Cypress test runs inside the browser and interacts with the web page

Preconditions (2)

Step 1: Open Cypress Test Runner

Step 2: Write a test that visits http://localhost:3000

Step 3: Click the button with id 'click-me'

Step 4: Verify that the text element with id 'message' changes to 'Button clicked!'

✅ Expected Result: The test runs inside the browser, clicks the button, and verifies the message text changes to 'Button clicked!'. The test passes.

Automation Requirements - Cypress

Assertions Needed:

Verify the page URL is correct after visit

Verify the button click triggers the expected text change

Best Practices:

Use cy.visit() to load the page

Use cy.get() with id selectors for elements

Use should() for assertions

Avoid hardcoded waits; rely on Cypress automatic waits

Write clear and simple test steps

Automated Solution

Cypress

describe('Cypress architecture test', () => {
  it('runs inside the browser and interacts with the page', () => {
    cy.visit('http://localhost:3000');
    cy.url().should('include', 'localhost:3000');
    cy.get('#click-me').click();
    cy.get('#message').should('have.text', 'Button clicked!');
  });
});

This test uses cy.visit() to open the web page inside the browser where Cypress runs.

We check the URL to confirm the page loaded correctly.

Then, we find the button by its id #click-me and click it.

Finally, we assert that the text element #message updates to 'Button clicked!'.

Cypress runs all commands inside the browser, so it can directly interact with the page DOM and listen to events.

Common Mistakes - 3 Pitfalls

Using hardcoded waits like cy.wait(5000) instead of relying on Cypress automatic waits

Using non-unique or complex selectors instead of simple id selectors

Trying to run Cypress tests outside the browser environment

Bonus Challenge

Now add data-driven testing with 3 different button ids and expected messages

Show Hint

Practice

1. What is a key feature of Cypress architecture regarding where tests run?

easy

A. Tests run on a cloud service without local browser access.

B. Tests run only on the server without browser interaction.

C. Tests run in a separate virtual machine outside the browser.

D. Tests run inside the browser, controlling the app like a real user.

Solution

1. Step 1: Understand Cypress test execution environment

   Cypress runs tests directly inside the browser, allowing it to control and observe the app as a user would.

2. Step 2: Compare with other options

   Other options describe architectures not used by Cypress, such as server-only or cloud-only test runs.

3. Final Answer:

   Tests run inside the browser, controlling the app like a real user. -> Option D

4. Quick Check:

   Cypress tests run in browser = A [OK]

Hint: Remember: Cypress tests run inside the browser environment [OK]

Common Mistakes:

• Thinking tests run only on the server
• Assuming tests run outside the browser
• Confusing Cypress with cloud-only test runners

2. Which of the following is the correct way to write a Cypress command to visit a webpage?

easy

A. cy.visit('https://example.com')

B. visit.cy('https://example.com')

C. cy.goTo('https://example.com')

D. browser.visit('https://example.com')

Solution

1. Step 1: Recall Cypress command syntax

   Cypress commands start with cy. followed by the command name, so cy.visit() is correct.

2. Step 2: Check other options for syntax errors

   Options A, B, and D use incorrect method names or object references not valid in Cypress.

3. Final Answer:

   cy.visit('https://example.com') -> Option A

4. Quick Check:

   Correct Cypress command syntax = C [OK]

Hint: Cypress commands always start with 'cy.' [OK]

Common Mistakes:

• Swapping method and object order
• Using non-existent Cypress commands
• Using browser object instead of cy

3. Given the following Cypress test code, what will be the output in the test runner?

describe('My Test', () => {
  it('checks page title', () => {
    cy.visit('https://example.cypress.io')
    cy.title().should('include', 'Kitchen')
  })
})

medium

A. Test throws a syntax error due to missing semicolons.

B. Test passes if the page title includes 'Kitchen'.

C. Test passes regardless of the page title content.

D. Test fails because cy.title() is not a valid command.

Solution

1. Step 1: Understand the test steps

   The test visits the Cypress example page and asserts the page title includes the word 'Kitchen'.

2. Step 2: Validate command correctness and assertion

   cy.title() is a valid Cypress command that gets the page title. The assertion should('include', 'Kitchen') checks if the title contains 'Kitchen'.

3. Final Answer:

   Test passes if the page title includes 'Kitchen'. -> Option B

4. Quick Check:

   cy.title() assertion success = D [OK]

Hint: cy.title() gets page title; check with should() [OK]

Common Mistakes:

• Thinking cy.title() is invalid
• Ignoring assertion logic
• Confusing syntax errors with missing semicolons

4. Identify the error in this Cypress test code snippet:

it('checks button click', () => {
  cy.visit('https://example.com')
  cy.get('#submit').click
})

medium

A. Incorrect selector syntax for cy.get().

B. cy.visit() should be inside beforeEach block.

C. Missing parentheses after click command.

D. Using cy.get() without chaining should() causes error.

Solution

1. Step 1: Review the click command usage

   The click command must be called as a function with parentheses: click().

2. Step 2: Check other parts of the code

   The selector #submit is valid, cy.visit() can be inside the test, and chaining should() is optional.

3. Final Answer:

   Missing parentheses after click command. -> Option C

4. Quick Check:

   click() needs parentheses = B [OK]

Hint: Always call commands like click() with parentheses [OK]

Common Mistakes:

• Forgetting parentheses on commands
• Misunderstanding selector syntax
• Thinking visit() must be in beforeEach

5. Why does Cypress run tests inside the browser instead of outside it, and what advantage does this provide?

hard

A. Running inside the browser allows Cypress to control the app like a user, making tests faster and easier to debug.

B. Running inside the browser reduces network traffic by avoiding server calls.

C. Running outside the browser is impossible due to browser security restrictions.

D. Running inside the browser enables tests to run without any JavaScript.

Solution

1. Step 1: Understand Cypress architecture purpose

   Cypress runs tests inside the browser to interact with the app as a real user would, giving precise control and observation.

2. Step 2: Identify benefits of this approach

   This approach makes tests fast, reliable, and easy to debug because Cypress can directly access the app's DOM and network.

3. Final Answer:

   Running inside the browser allows Cypress to control the app like a user, making tests faster and easier to debug. -> Option A

4. Quick Check:

   Browser test run = faster, easier debug = A [OK]

Hint: Tests inside browser = real user control + fast debugging [OK]

Common Mistakes:

• Thinking tests run outside browser for speed
• Confusing network traffic with test speed
• Believing tests run without JavaScript