GSoC 2025 Final Project Report

2 November 2025

By Syed Ali Ul Hasan

image

About The Palisadoes Foundation & Talawa

The Palisadoes Foundation sponsors open-source software projects that help community groups organize their daily activities and improve operational efficiency. The foundation maintains several projects, including SwitchmapNG and Talawa.

Talawa is an open-source platform designed to help community-based organizations manage events, funds, posts, and memberships efficiently. It is available for both mobile and web platforms.

SwitchmapNG generates HTML pages displaying detailed information about a set of Ethernet switches, providing network administrators with a clear view of their network infrastructure.

Project Outline & Deliverables

My project aimed to enhance the testing strategy across the Talawa repositories by implementing new techniques and automation. The main deliverables included:

Technologies Used

Why E2E Testing was necessary?

Previously, the Talawa codebase relied primarily on unit testing, which ensured that individual components worked correctly. However, it lacked a mechanism to validate how these components interacted as a complete system. This meant that the developer had to rely heavily on manual UI testing to ensure that the application functioned smoothly after updates.

Introducing E2E testing helped bridge this gap by validating complete user flows across the API, Admin, and Mobile applications ensuring that all parts of the system worked together seamlessly before deployment to production.

Setting up E2E testing using Cypress.io

We chose Cypress.io for implementing end-to-end (E2E) tests on the Talawa Admin web application due to its rich feature set, including its interactive test runner, seamless integration with GitHub Actions, real-time debugging capabilities, and automatic waiting mechanism.

Cypress provides a developer-friendly environment that makes writing and maintaining UI tests efficient and reliable.

Implementing the Base Setup

The first pull request introduced the base Cypress setup within the Talawa Admin repository.

This included creating a new cypress/ directory at the project root, structured as follows:

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

Additionally, new scripts were added to the package.json to support different Cypress execution modes:

    "cypress:run": "cypress run",
    "cypress:open": "cypress open",
    "start-server": "start-server-and-test serve http://localhost:4321",
    "cy:open": "npm run start-server cypress:open",
    "cy:run": "npm run start-server cypress:run"

This setup allowed both interactive and headless test execution.

The PR also introduced Commitlint to enforce standardized commit messages across the project.

PR #3988: [GSOC] feat: add cypress E2E tests and commitlint

image

CI: Cypress Tests Workflow using Github Actions

The next step involved integrating Cypress tests into the CI/CD workflow to ensure that every pull request is automatically tested.

Cypress provides an official Github Action, which was utilized to run tests directly within the workflow.

This enhancement was introduced in PR #4060 [GSOC] ci: added cypress tests workflow

A new Run-Cypress-Tests check was introduced in the pull-request.yml file. The workflow performs the following steps:

  1. Sets up the Talawa API (backend) using the latest develop branch.
  2. Builds and serves the Talawa Admin frontend.
  3. Executes Cypress E2E tests using the Cypress GitHub Action.

The image below shows that this check runs in parallel with the “Test Application” check, ensuring faster CI cycles:

image

Code Coverage Report

The next step was to introduce code coverage reporting for Cypress tests. Cypress provides a dedicated npm package, @cypress/code-coverage, which was integrated into the project. Additionally, vite-istanbul was configured to instrument the application and track test coverage during E2E runs.

This was implemented in PR #4077, which added a detailed coverage report that helps monitor the effectiveness of test suites and identify untested areas in the codebase.

image image

Pre-Commit Check to Ensure Page Object Model (POM) Consistency

All E2E tests were written following the Page Object Model (POM) pattern encapsulating page interactions within dedicated classes and calling these methods within test files. To maintain consistency, a pre-commit script was introduced that validates whether the tests adhere to this structure.

The script scans test files under cypress/e2e/ and flags any direct use of Cypress commands (like cy.get(), cy.click(), etc.) instead of using corresponding page object methods.

const forbiddenMethods = [
  'get', 'contains', 'find', 'children', 'closest',
  'filter', 'first', 'last', 'next', 'prev', 'siblings',
  'click', 'dblclick', 'rightclick', 'type', 'select',
  'check', 'uncheck', 'trigger', 'clear', 'scrollIntoView',
  'should', 'and', 'within',
];
 
const forbiddenPatterns = forbiddenMethods.map(m => `cy.${m}(`);
 
const files = sync("cypress/e2e/**/*.ts");
 
let hasError = false;
 
files.forEach(file => {
  const content = readFileSync(file, "utf8");
  forbiddenPatterns.forEach(pattern => {
    if (content.includes(pattern)) {
      console.error(`Found "${pattern}" in ${file}`);
      hasError = true;
    }
  });
});
 
if (hasError) {
  console.error("❗ POM violations detected. Please refactor the tests to use page objects.");
  process.exit(1);
} else {
  console.log("✅ All e2e tests follow POM.");
}

The image below demonstrates how the script reports violations and confirms success when all tests comply with the POM structure:

image

At the completion of the GSoC timeline, the E2E Coverage on the Talawa Admin Web was ~60%.

Statements   : 59.15% ( 2855/4826 )
Branches     : 45.83% ( 1431/3122 )
Functions    : 53.94% ( 677/1255 )
Lines        : 59.03% ( 2526/4279 )

Setting Integration Tests on the Flutter Application

Flutter provides a powerful Integration Testing package that allows developers to test entire app flows, ensuring that different widgets and screens work together as expected. This package was used to set up the integration test suite for the Talawa Mobile application.

A new folder, integration_test, was introduced at the root of the project to organize and manage these tests.

Following the same structured approach used in Cypress (Page Object Model), the Flutter integration tests adopt the Robot Pattern a clean, maintainable architecture for handling UI interactions.

integration_test/
├── app_test.dart             # Main entry point for integration tests
├── robots/
│   └── login_form_robot.dart # Contains reusable robot class for login flow
└── helper.dart               # Utility/helper functions used in tests

In this setup, each robot encapsulates the logic required to interact with a specific screen or feature - such as login, logout, or navigation. Keeping the actual test cases concise and readable.

Test Execution

The integration tests are executed through the main entry file app_test.dart.

These tests simulate complete user flows from app launch to login, performing actions, and logging out to ensure that the user experience remains consistent across updates.

Tests can be executed using the following command:

flutter test integration_test/app_test.dart

Below is an example test that validates the Admin login and logout flow:

void main() {
  late LoginFormRobot loginFormRobot;
  late LogoutRobot logoutRobot;
 
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();
 
  setUpAll(() async {
    await dotenv.load(fileName: ".env");
 
    debugPrint("Environment variables loaded");
 
    debugPrint("API_URL = ${dotenv.get('API_URL')}");
  });
 
  group("E2E Tests : ", () {
    testWidgets(
      "For Admin",
      (WidgetTester tester) async {
        app.main();
 
        await tester.pumpAndSettle();
 
        final graphqlConfig = locator<GraphqlConfig>();
        graphqlConfig.initializeForTesting(dotenv.get('API_URL'));
 
        await Future.delayed(const Duration(seconds: 2));
 
        loginFormRobot = LoginFormRobot(tester);
        devPrint("-> Login as Admin");
        await loginFormRobot.loginAdmin();
        devPrint("✓ Admin logged in successfully");
        logoutRobot = LogoutRobot(tester);
        devPrint("-> Logout Admin");
        await logoutRobot.logout();
        devPrint("✓ Admin logged out successfully");
 
        devPrint("✓ Admin test completed successfully");
      },
      timeout: const Timeout(Duration(minutes: 5)),
    );
  });
}

The Integration Test Coverage at the end of GSoC timeline was ~40%.

Other Deliverables & Additions

Integrating Keploy's PR Agent

Keploy's PR Agent was integrated to automate the generation of unit tests. With each pull request, the agent analyzes the code changes and provides a comment suggesting possible unit tests, streamlining the testing workflow and improving overall test coverage.

Security Testing using OWASP ZAP

Security testing is crucial to identify potential vulnerabilities early in the development process, ensuring that the application remains safe against common threats like injection attacks, misconfigurations, and insecure dependencies.

Although not part of the original project scope. Integrating OWASP ZAP into the CI helps maintain continuous security validation with every code change

Report after the check is successful:

image

Relevant PR's made during the GSoC period

Follow-Up Issues

As development progresses, I am raising several follow-up tasks to further strengthen the testing framework and improve overall coverage.

For any further improvements or new issues, I will continue to collaborate and contribute alongside.

Other Links:

During the period, I have properly documented the project for future contributors & also wrote a small blog during the period:

Acknowledgement

I would like to extend my heartfelt gratitude to my mentors Kevonia Tomlinson, Tasneem Koushar and Md Noman Khan for generously investing their time and effort in guiding me throughout my Google Summer of Code journey. Their constant support, valuable feedback, and technical insights greatly contributed to the success of my project. I am truly grateful for the patience and encouragement they showed as I learned and grew through this experience.

Finally, I would also like to thank the Palisadoes Foundation community for providing such a collaborative and inspiring environment that made this journey both educational and rewarding.

I look forward to staying connected with the community and continuing to contribute to its open-source initiatives in the future.

Thank you all for making GSoC 2025 such a memorable and transformative experience for me.

My Learnings

Plans for Future

~ Syed

LinkedIn
X