Interview Questions
Cypress is a modern, all-in-one testing framework for web applications that executes tests in the same run loop as the application. Unlike Selenium, which runs outside the browser and uses WebDriver for automation, Cypress runs inside the browser, providing better control, real-time reloads, and automatic waiting. It offers built-in assertions, stubbing, and spying capabilities without requiring additional tools.
Key features include: 1) Automatic waiting and retry-ability, 2) Real-time reloads, 3) Consistent results due to automatic waiting, 4) Time travel and debugging capabilities, 5) Network traffic control, 6) Screenshots and videos of test runs, 7) Cross-browser testing support, 8) Built-in assertion library, 9) Stubbing and spying on network requests, 10) Interactive test runner.
The Cypress Test Runner is an interactive interface that allows you to see commands as they execute, view the application under test, and inspect the DOM. It provides features like time travel, real-time reloads, and debugging tools. The Test Runner shows the command log, application preview, and detailed error messages when tests fail.
Cypress can be installed using npm: 'npm install cypress --save-dev'. After installation, initialize it using 'npx cypress open' which creates the cypress directory with example specs and configuration. The configuration file (cypress.config.js) can be customized for project-specific settings.
A basic Cypress test uses describe() blocks for test suites and it() blocks for individual tests. Tests typically follow the pattern: visit a page, get an element, interact with it, and make assertions. Example: describe('My Test Suite', () => { it('performs an action', () => { cy.visit('/'); cy.get('button').click(); cy.contains('Result').should('be.visible'); }); });
Cypress commands are chainable methods that perform actions, assertions, or retrieve elements. They are asynchronous but handle promises automatically. Commands follow a sequential order and include automatic retry-ability and waiting. Common commands include cy.visit(), cy.get(), cy.click(), cy.type(), and cy.should().
Cypress automatically handles asynchronous operations through its command queue. Commands are executed sequentially, and Cypress automatically waits for commands to complete before moving to the next one. It includes built-in retry-ability and timeout mechanisms, eliminating the need for explicit waits or async/await syntax.
Aliases are references to elements, routes, or values that can be reused throughout tests. They are created using cy.as() and referenced using @alias syntax. Aliases help reduce code duplication and make tests more maintainable. Example: cy.get('button').as('submitBtn') and later cy.get('@submitBtn').click().
Cypress includes Chai assertions and extensions through .should() and .expect(). Assertions automatically retry until they pass or timeout. Common assertions include checking visibility, text content, element states, and DOM properties. Example: cy.get('element').should('be.visible').and('contain', 'text').
cy.get() searches for elements in the entire DOM and starts a new command chain. cy.find() searches for elements within the previous subject's DOM and continues the existing chain. cy.get() is used for initial element selection, while cy.find() is used for finding nested elements.
Page navigation is handled using cy.visit() for direct URL navigation and cy.go() for browser history navigation. Cypress automatically handles waiting for page loads and can be configured with baseUrl in cypress.config.js. Navigation events can be verified using cy.url() and cy.location().
Fixtures are external pieces of static data used in tests, typically stored in JSON files in the cypress/fixtures directory. They are accessed using cy.fixture() and commonly used for test data, mock responses, and configuration. Example: cy.fixture('users.json').then((users) => { // use data }).
Environment variables are managed through cypress.config.js or cypress.env.json files. They can be accessed using Cypress.env(). Different configurations can be set for different environments, and sensitive data should be handled through environment variables rather than being committed to source control.
Custom commands are reusable functions added to the cy object using Cypress.Commands.add(). They help reduce code duplication and create domain-specific testing language. Commands can be organized in support/commands.js and should follow Cypress command patterns for consistency.
Cypress can intercept, stub, and spy on network requests using cy.intercept(). It provides capabilities to mock responses, verify request parameters, and control network behavior. Network requests can be waited upon using cy.wait() and assertions can be made on request/response data.
Hooks are functions that run at specific times in the test cycle: before(), beforeEach(), after(), and afterEach(). They're used for test setup and cleanup, such as resetting state, logging in, or clearing data. Hooks can be defined at suite or global levels.
Cypress offers multiple debugging tools: .debug() command to pause execution, cy.log() for logging, Chrome DevTools integration, and Time Travel feature in Test Runner. The Command Log shows detailed information about commands and failures for debugging.
Retry-ability is Cypress's automatic retrying of commands and assertions until they pass or timeout. It handles async operations and DOM changes automatically. Commands like cy.get() and assertions automatically retry, while actions like .click() do not retry to prevent unintended side effects.
Iframes are handled using cy.iframe() plugin or by getting the iframe element and using its contents. The .within() command can be used to scope commands to the iframe context. Special consideration is needed for cross-origin iframes due to same-origin policy.
Viewport commands (cy.viewport()) control the size and orientation of the viewport during tests. They're useful for testing responsive designs and mobile views. Viewport can be preset using config or changed during tests, affecting how elements are rendered and interacted with.
Page objects can be implemented as classes or objects in separate files, containing selectors and methods for interacting with specific pages. They help organize test code, improve maintainability, and provide reusable page interactions. They can be extended for complex page hierarchies.
Complex authentication can be handled through programmatic login (cy.request()), session storage, custom commands, or API calls. Token-based auth can be managed through interceptors or local storage. Consider using cy.session() for session caching and performance optimization.
Dynamic content requires robust element selection strategies, proper waiting mechanisms, and handling of async updates. Use cy.contains() with regular expressions, data-* attributes for selection, and proper retry-ability patterns. Consider implementing custom commands for common dynamic scenarios.
Data-driven testing can be implemented using fixtures, external data sources, or programmatically generated data. Use cy.wrap() for handling external data, consider using before() hooks for data setup, and implement proper data cleanup strategies.
Complex workflows require proper test organization, state management, and error handling. Break down workflows into smaller, reusable steps using custom commands, implement proper verification points, and consider using the command chain pattern for better maintainability.