Mid Term Progress Report

Mid Term Progress Report

Welcome to another article in my series documenting my internship journey at Outreachy working on “Improving the Wiki Education Dashboard test suite” . In this progress report, I will summarize the work I’ve completed over the past six weeks, the modifications I’ve made, the ongoing task and task pending completion.

Project Overview

The goal of this project is to enhance the reliability, maintainability, and overall developer experience of the dashboard. A major issue I’ve been addressing is the frequent intermittent failures in the test suite, which has led to the dashboard becoming unreliable. Additionally, the GitHub CI build time is quite lengthy, averaging around 30–35 minutes, which I aim to optimize. Below are the key sections of the project, the key accomplishments achieved in each section, the ongoing task and task pending completion.

1 . Analyzing and Fixing Failed Build Tests

Key Accomplishments

In this step of the project, I focused on analyzing and identifying patterns in the intermittent test failures. My efforts were centered on resolving these specific issues, not the entire test suite. The main problems I identified and fixed were:

  • Dependency on External APIs: Many tests were failing due to reliance on external APIs, which were sometimes unavailable due to connectivity issues or the API being unreachable. To fix this, I mocked the tests that relied on these external APIs, reducing their dependence on external services and improving the test reliability.

  • Feature Tests with User Interactions: Some feature tests that simulated user interactions were failing because components didn’t render properly within the default wait time set by the testing tool (Capybara). This was mainly due to components taking longer to load, especially when fetching data from external sources. I resolved this by increasing the default wait time, ensuring that components had enough time to load and render correctly before interactions occurred.

  • Test Refactoring: I also reviewed and analyzed the tests that were causing failures. Some tests were refactored to ensure that components were properly displayed before being interacted with.

Since implementing these fixes, the intermittent failures I identified have not occurred again. I continue to monitor the test suite and address any new intermittent issues that arise as they come up.

2. Optimizing the RSpec Test Suite and Workflow Optimizations on the CI/CD Pipeline

Originally, these were separate sections in my project report, but they are more interconnected than distinct. The goal of this part of the project is to optimize the RSpec test suite, focusing on refactoring large, complex, and slow tests that contribute to the overall slowness of the CI build. Improving these tests will ultimately reduce the CI build time.

Key Accomplishments

  • Extending the GitHub Workflow for Better Debugging:
    To enhance the debugging process, I began by extending the GitHub workflow. This ensures that failures within the workflow can be more easily analyzed. When a failure occurs, the workflow now uploads a screenshot or a failure log as a build artifact, which can be downloaded to review the state of the test at the moment of failure. This improvement enables faster identification and resolution of issues, reducing downtime and ensuring more reliable CI/CD performance.

Ongoing Tasks

  • Optimizing Slow Tests

    Currently, my focus is on optimizing the slow tests in the RSpec suite. I am systematically analyzing the tests that take the longest to execute and working on refactoring them to improve performance. By reducing the execution time of these tests, it will directly impact the overall CI build time, making the pipeline faster and more efficient.

Tasks Pending Completion

  • Writing New Tests to Cover Uncovered Code

    In addition to optimizing existing tests, I am writing new tests to cover previously uncovered sections of the code. This ensures comprehensive test coverage, reducing the chances of undetected issues and contributing to a more robust CI/CD pipeline.

Conclusion

So far, the steps to accomplish the project haven’t followed a strict step-by-step approach as initially planned. Instead, I’ve moved ahead with some tasks and then revisited earlier steps as new challenges arose. This flexibility is part of the reality of software development.

Despite this, completing the tasks outlined above has provided me with a deeper understanding of the project, Ruby on Rails, and testing practices. One of the benefits of this project is that it has exposed me to every part of the codebase, allowing me to gain a thorough understanding of the system. I’ve also become better at identifying issues and fixing them as I progress.

Thank you for following my journey through these articles. I look forward to sharing more about my progress and what I continue to learn throughout this project. 😀