Skip to main content

End to End Testing

This project uses Cypress for comprehensive end-to-end testing to ensure the application works correctly from a user's perspective.

Prerequisites​

Before running Cypress tests, ensure you have the following setup:

Talawa API Setup​

  1. Important: The Talawa API must be properly installed, configured, and running before executing any Cypress tests. The tests depend on API endpoints being available and functional.
  2. Please follow the complete installation guide at: https://github.com/PalisadoesFoundation/talawa-api/blob/develop/INSTALLATION.md

Application Server​

Ensure your local development server is running on http://localhost:4321.

Directory Structure​

The tests follow the Page Object Model pattern for maintainability.

cypress/
├── e2e/                    # End-to-end test specifications
│   └── example_spec/       # Related tests
├── fixtures/               # Test data and mock files
│   └── users.json         # User test data
├── pageObjects/           # Page Object Model files
│   └── auth/              # Authentication page objects
└── support/               # Support files and custom commands
    └── commands.ts        # Custom Cypress commands

Key Components:​

  1. e2e/: Contains all test specification files organized by feature
  2. fixtures/: Static data used in tests (JSON files, images, etc.)
  3. pageObjects/: Page Object Model implementation for maintainable test code
  4. support/: Custom commands and utilities to extend Cypress functionality

Running Tests​

Follow these steps to run end to end tests

Available Commands​


# Open Cypress Test Runner (Interactive Mode)
# Preferred for Debugging

pnpm run cy:open

# Run all tests in headless mode

pnpm run cy:run

Running Specific Tests​

There are multiple testing modes.

Interactive Mode​

For running specific tests with visual feedback, use the Interactive Mode where you can view all test specs and run individual tests:

pnpm run cy:open

Headless Mode​

For running specific tests in headless mode, first manually start your application at http://localhost:4321, then use the following commands:

# Run tests in a specific folder
pnpm run cypress:run --spec "cypress/e2e/dashboard_spec/**/*"

# Run a specific test file
pnpm run cypress:run --spec "cypress/e2e/login_spec/login.cy.ts"

Writing Tests​

Follow these best practices when writing tests.

Page Object Model​

This project follows the Page Object Model pattern for better test maintenance:

// Example usage of page objects
import { LoginPage } from '../pageObjects/auth/LoginPage';

const loginPage = new LoginPage();

it('should login successfully', () => {
  loginPage.verifyLoginPage().login(userData.email, userData.password);
});

Custom Commands​

Custom Cypress commands are defined in cypress/support/commands.ts to provide reusable functionality across tests.

GraphQL Utilities​

To reduce duplication and improve reliability, use the GraphQL helpers defined in cypress/support/graphql-utils.ts. These helpers intercept GraphQL requests by operationName and provide a consistent API to mock, alias, and await calls.

The interceptor respects CYPRESS_API_URL via Cypress.env('apiUrl'), and falls back to **/graphql if not set.

// Mock a successful operation using a fixture
cy.mockGraphQLOperation(
  'OrganizationListBasic',
  'api/graphql/organizations.success.json',
);

// Wait for the mocked operation
cy.waitForGraphQLOperation('OrganizationListBasic');

// Mock a GraphQL error response
cy.mockGraphQLError(
  'CreateOrganization',
  'Organization name already exists',
  'CONFLICT',
);

// Alias a live operation and wait for it
cy.aliasGraphQLOperation('OrganizationListBasic');
cy.waitForGraphQLOperation('OrganizationListBasic');

Mock cleanup and test isolation​

Because testIsolation is set to false, Cypress intercepts can persist between tests in the same spec. Always clear GraphQL mocks after each test to avoid leaking intercepts across tests or shards:

afterEach(() => {
  cy.clearAllGraphQLMocks();
});

If multiple tests in the same spec target the same operationName, explicitly clean up at the end of each test:

it('mocks a successful query', () => {
  cy.mockGraphQLOperation(
    'OrganizationListBasic',
    'api/graphql/organizations.success.json',
  );
  // test steps...
  cy.clearAllGraphQLMocks();
});

Best practices:

  • Prefer testIsolation: true for new specs when possible.
  • In parallel/sharded runs, mocks can race if not cleared; keep mocks scoped per test and always reset intercepts after each test.
  • If multiple mocks target the same operation, ensure explicit cleanup between them or scope each mock to a single test to avoid collisions.

Test Data​

Use fixtures for consistent test data:

// Load test data from fixtures
cy.fixture('users').then((users) => {
  // Use users data in tests
});

Fixture library structure​

Fixtures are organized by domain under cypress/fixtures/ to keep tests deterministic and consistent:

  • auth/ - credential and user fixtures for login flows
  • admin/ - organizations, events, people, action items, advertisements, tags, venues
  • user/ - posts, volunteers, campaigns, donations
  • api/graphql/ - GraphQL responses grouped by operationName

Datasets are intentionally minimal, include edge cases (empty arrays, long names, Unicode), and avoid PII.

Note: auth/users.json contains user metadata (id, name, email, role). Use auth/credentials.json for login credentials in Cypress tests.

Example usage with GraphQL utilities:

cy.mockGraphQLOperation(
  'OrganizationListBasic',
  'api/graphql/organizations.success.json',
);

cy.mockGraphQLOperation(
  'CreateOrganization',
  'api/graphql/createOrganization.success.json',
);

cy.mockGraphQLOperation(
  'CreateOrganization',
  'api/graphql/createOrganization.error.conflict.json',
);

Example usage with JSON fixtures:

cy.fixture('admin/organizations').then((data) => {
  expect(data.organizations).to.have.length(2);
});

Test Coverage Report​

After running your Cypress tests, you can generate detailed HTML coverage reports to analyze code coverage:

  1. Run Cypress tests to collect coverage data:

    pnpm run cy:run

  2. Generate HTML coverage report using nyc:

    npx nyc --reporter=html

  3. View the coverage report in your browser:

    open coverage/index.html

The HTML report provides an interactive view of:

  1. Overall coverage percentages (statements, branches, functions, lines)
  2. File-by-file coverage breakdown
  3. Detailed line-by-line coverage highlighting
  4. Uncovered code sections for easy identification

Note: Coverage data is collected during test execution and stored in the .nyc_output directory. The HTML report is generated in the coverage/ directory.

Contributing​

When adding new tests:

  1. Follow the existing directory structure
  2. Use Page Object Model pattern
  3. Add appropriate fixtures for test data
  4. Ensure tests are independent and repeatable
  5. Document any new custom commands

For more information about Cypress testing, visit the official Cypress documentation.