== Profile Information
Name: Formasit Chijoh Fokunang
Nickname: formasit
Github: Formasitchijoh
Email: formasitf@gmail.com/manoica2023@gmail.com
Phone Number: +237-675-718-328
Location: Cameroon
Time Zone: Cameroon (GMT + 1)
== Meeting with mentors:
I am reachable anytime through email, slack, and any communication channel
GMT + 1, 6:00 AM to 10:00 PM
= Synopsis
== [WikiEducation Dashboard] Improve the Wiki Education Dashboard test suite
Wiki Education Dashboard is a Ruby on Rails application that provideswith a server-rendered fronted and contains a with a mixed React and Redux.ontend, It providesincorporating both React and Redux. It tracking ands and provides statistics for hundreds of thousands of editors on Wikipedia and other Wikimedia wikis.The Dashboard codebase uses a comprehensive suite of Ruby tests, The codebase including unit and featurees a comprehensive suite of Ruby tests, to maintainsuch as unit and feature tests, to ensure functionality.However, the current test suite is fails oftenHowever, takingthe current test suite frequently fails and takes approximately 30 to 35 minutes to run (on GitHub CI),. andIt is overall fairlyalso fragile, with intermittently test failing tests .The focusures. This project will be on identifying andfocus on improving the quality and performance of the test suite, optimizing execution times, and increasing test coverage. Strategies such aslike parallelizinging and refactoring slow tests,s will be used to create a more reliable and efficient platform. and refactoring slow tests will be employed to achieve a more reliable and performant platform. Improving the Dashboard test suite will drasticalEnhancing the Dashboard’s test suite will significantly improve the developer experience andwhile making the platform performantmore scalable and scalableperformant
== Mentors
Sage Ross(@Ragesoss), Sulagna Saha(@saha23s)
= (In Progress)
== Deliverables
1. Identifying and fix all test that fail intermittently
2. Establish a test suite that passes 20 consecutive runs on CI
3. Refactor, rewrite, and improve code quality and test coverage of areas of the code holes, filling gaps in test coverage and writeing tests for untested LOCed lines of code (LOC)
4. dDocument test cases in a way that canallows them to evolve for future reference.
== Implementation Details
The Mmajor scope of this project will focus on the ruby rspec test suitefocuses on the Ruby RSpec test suite for the Ruby on Rails backend. This suite includes unit tests for individual class files as well as browser-driven feature (integration) tests that interact with both the client-side UI and server-side behavior. Improving this section will significantly enhance the performance of the entire test suite.
While the primary objective will be to evaluate the Ruby test suite and its recent CI logs to identify intermittently failing tests, for the ruby on rails backend which contain unit tests of individual class files as well as browser-driven feature (ietheir underlying causes, integration)and tests that interact with both the client-side UI and the server-side behaviorcontribute to long execution times, hence improving this section will greatly affect the performance of the entire test suite.
The primary focus will be evaluating the test suite and its recent CI logs to identify intermittently failing testsI will also address the JavaScript test suite. However, their causes,the main focus will remain on Ruby. and tests that significantly contribute to long execution times and proper evalution of external API that the system interacts withProper evaluation of the external APIs that the system interacts with will be conducted alongside these efforts. The project will also target areas of the Ruby codebase withthat exhibit gaps in test coverage and LOC with unwrittenlines of code (LOC) that lack test ,s. rewriting bBoth the tests and the underlying codee will be rewritten as needed
=== STEP-I
The current API of the system currently through error intermittently,---------------------
* The first step will be to,The current API of the system throws errors intermittently. To address this:
* Run unit test each test for the different controllers, models and services in isolation to ensure it works as expected
*Identify any patterns of failures in the test,
* Identify the cause of the failure and document them,
* Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi* Unit tests will be ran on each controller, often fail intemittenlymodel, due to at least some of these problems,
* The LiftWing API has different responses than what the specs were written aroundand service in isolation to ensure they work as expected.
* These third party endpoint will be tested under different condition to analyze it response and update existing to cover the response gotten from this endpoint RSpec test and code that use these endpoint.
* These endpoint will be tested* Identify patterns of test failures, to identify its’s interactions with the system and Why it failsand analyze logs to trace the causes.
* Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete,Document each failure and its cause.
Features relying on external APIs such as the LiftWing API, ReferenceCounter API, Commons Wiki, and WikiApi often fail intermittently. These issues stem from
* Inconsistencies in API responses and network reliability.
* LiftWing API: The API returns responses that differ from the ones the test specs were written around. this is relatively slow for development purposes,
* Recent Sentry logs and development logs will, be reviewed to identify the different failurTests need to be updated to handle these variations in responses.
* Perform extensive testing under different conditions to analyze the responses from these third-party APIs and refactor existing RSpec tests and related code to account for the observed behavior.
* Investigate why these APIs interact inconsistently with the system and document the conditions that cause failures.
The current CI/CD pipeline takes approximately 30 to 35 minutes to complete, and how they have evolved overtime,
* Identify any pattern and dependencies.which is inefficient for development.
* Review recent Sentry logs and development logs to identify failure patterns and their evolution over time.
* Analyze the slowest API requests and test cases identified by the test suite, Uusing the most slowest apI request and test that are identified by the test suiteimers to determine the execution time of each request.
Based on this data, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them and improve the performancimplement strategies to optimize performance and reduce pipeline runtime.
* I am currently working on issue of writing comprehensive test for the javascript and ruby test suite and from the issue that was raised here i have been going through all the failures that have come upI am currently addressing issues in both the JavaScript and Ruby test suites. Comprehensive tests are being written to cover gaps identified during previous contributions.
Failures encountered during the contribution stage and am currently fixing them,are being systematically reviewed and resolved. i ill I will continue to do so until ofix these issues through the Outreachy result declaration and all through the bonding phase.
=== STEP-III
After proper analysis of the entire test suite and identifying the different causes of intermittent failures and their causes , The project will employee automation testing strategy that will range from
* updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test---------------------
* Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate formatAfter analyzing the entire test suite and identifying the causes of intermittent failures, the next step is to implement solutions to stabilize the system and improve performance. This will involve a range of technical strategies and improvements:
* Fixing Unit Tests
* After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the article Based on the results from the isolated unit tests, each of these models controllers and request test case will be reevaluated to improve the find issue
* All existing modules will be properly tested to ensure full test coverage,refactor and update tests to handle breaking changes. fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new featureFocus will be on:
* Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance,
* Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected. * Controller and Model Tests: Adjusting test logic to handle edge cases and undefined behaviors identified in STEP-I.
* External Service Tests: Improving mock strategies for third-party services (LiftWing, ReferenceCounter, etc.) by implementing enhanced stubbing/mocking mechanisms for unpredictable API responses.
* New unit tests will be written to cover previously untested code paths, ensuring all models, services, and controllers are fully covered.
* Enhancing External API Handling
Following the analysis in STEP-I, all API-related tests will be restructured:
* Update specs and tests to accommodate the changing response structure. Use dynamic response validation mechanisms such as JSON Schema validation to account for different responses.
* Improve the current retry mechanisms in API calls to handle intermittent failures due to network issues, ensuring more consistent API interactions.
* Integration Tests: Perform additional integration tests where the system interacts with the API, simulating real-world scenarios such as rate limiting, slow responses, and server errors.
End-to-End System Testing (JavaScript & Ruby)
* The server-rendered parts of the system, including both Ruby backend and JavaScript/JSX frontend, will be tested end-to-end using Capybara and Selenium WebDriver. This will:
* Using Sentry logs* Simulate user interactions across the entire system, ensuring that controllers, views, test suites will be improves to reduce test run and equally optimize test performanceand front-end logic function seamlessly together.
* cTest cross-system functionality like user flows, login, data processing, and saving features.
Optimization of the CI/CD Pipeline
* Parallel testing will involve dividing the test suite into smaller groups that run concurrently across multiple CPU cores or machines, reducing the total CI/CD pipeline runtime
* Selective test execution will track codebase changes and trigger only the necessary tests based on dependencies, reducing redundant executions
* Handling API rate limits and timeouts will be addressed by implementing throttling, rate-limiting, and retry mechanisms, such as exponential backoff, to minimize failures from API rate limits
* API latency monitoring and fallback mechanisms will ensure external API latency is monitored with tools like Sentry or New Relic, and fallback mechanisms will be introduced to handle delayed responses effectively.
* Create new test Data configurations and ensure existing once are improved to work
=== STEP-III
* Run end to test to ensure Existing iintermittent test failures are resolvedExecute comprehensive end-to-end tests across the Ruby backend and JavaScript frontend to confirm all components interact seamlessly and fulfill user flows,
* Validate that unit tests have been successfully refactored and cover edge cases, ensuring all controllers, models, and services are functioning correctly without breaking changes.
* Monitor the performance of external API interactions to ensure stability and reliability, verifying that the retry mechanisms effectively handle intermittent network issues and that API responses conform to the updated specs.
* Confirm that the CI/CD pipeline runtime has been successfully reduced to under 20 minutes by analyzing execution times for all test suites and ensuring parallel testing is optimized.
* Write a guide to assist developers in navigating and diagnosing issues in failing testsCreate a developer guide detailing troubleshooting steps for common test failures and highlight the strategies implemented to enhance the testing process.
* Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is fromCollect feedback from developers regarding the test suite and documentation to identify areas for further improvement and refinement.
== Future Goals:
Will be implemented if all above-mentioned milestones are achieved and completed successfully and approved by the mentors, also desired to be taken up after Outreachy.
*Increase the JavaScript/JSX statement coverage to 90%
*Continue monitoring the system platform to ensure all test pass properly and are effective and handle new code
=== Timeline
=== October 29 - November 26:
* Continue making contributions to the Wikieducation DashboardEducation Dashboard
* Ongoing analysis of the existing test suite, focusing on documenting flaky tests
* Run unit tests for different controllers, models, and services in isolation to ensure they work as expected and identify patterns of failures.
* Document the causes of failures identified during testing
=== November 26 - December 9
* Community bonding period
=== December 9 - December 14* Begin with user research to identify further areas of improvement in the existing test suites.
* Ongoing analysis of the existing test suite, focusing on documenting flaky tests
=== December 9 - December 14 (Week 1 )
* Begin with the user research to identify further areas of improvements in the existing test suitesThird-Party API Analysis:
* The first step will be to run unit test each test for the different controllers* Analyze failures in system api and features that utilize third-party APIs (LiftWing, models and services in isolation to ensure it works as expected and identify any patterns of failures in the testReferenceCounter, identify the cause of the failure and document them,
=== December 16 - Jan 5 (Week 2)Commons Wiki, WikiApi).
* Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi, often fail intemittenly, due with at least some of these problems, the LiftWing API has different responses than what the specs were written aroundTest these APIs under different conditions to analyze responses and update existing RSpec tests to handle varying response formats.
to different responses returned than what the Rspec expect, these third party endpoint will be tested under different condition to analyze it response and update existing to cover the reponse gotten from this endpoint Rpec and code that use these enpoint.
These endpoint will be tested* Review recent CI , to identify its’s interactions with the systemSentry and development logs to identify failure patterns and Why it failsperformance issues.
=== Jan 7 - Jan 12* Analyze slow API requests and tests to determine execution times and strategies for optimization..
=== December 16 - December 21 (Week 2)
(Week 3)* Refactor unit test for test that fails intermittently and write new test for uncovered section of the ruby rspec test suite
* create new test Data configurations and ensure existing once are improved to work=== December 23 - Jan 5 (Week 3 & 4)
* Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete, this is relatively slow for development purposes, recent Sentry logs and development logs will, be reviewed to identify the different failure, and how they have evolved overtime, and identify any pattern and dependencies. Using the most slowest apI request and test that are identified by the test suite, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them. And improve the performance.ontinue Refactor unit test for test that fails intermittently and write new test for uncovered section of the ruby rspec test suite
=== Jan 14 - Jan 19* Create new test data configurations and ensure existing ones are improved.
* updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test=== Jan 7 - Jan 12 (Week 5)
* Buffer time for previous weeks* Analyze previous work and incorporate feedback from the mentor
* Mid point* Discuss potential improvements to existing tests and gather feedbackck on recent work.
=== Jan 21 - Jan 26* Mid-point feedback gathering
=== Jan 14 - Jan 19 (Week 56)
* Discuss how to improve exiting test and get feedback on the exisitng work
* Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate format * Perform additional integration tests where the system interacts with the API, simulating real-world scenarios such as rate limiting, slow responses, and server errors.
*Using Sentry logs * Improve the current retry mechanisms in API calls to handle intermittent failures due to network issues, test suites will be improves to reduce test runensuring more consistent API interactions.
* Update specs and equally optimize test performance.
=== January 28 - Feb 3tests to accommodate the changing response structure.
=== Jan 21 - Jan 26 (Week 6 7)
* After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the articles, each of these models controllers and request test case will be reevaluated to improve the find issueFeedback and External API Testing:
* Discuss improvements to existing tests and gather feedback on recent work.
* Continue working on the improving the test for external api
=== Feb 5 - Feb 10* Use Sentry logs to improve test suites, focusing on reducing runtime and optimizing performance
=== January 28 - Feb 3 (Week 78 )
* All existing modules will be properly tested to ensure full test coverage, fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new featureFocused Testing on Problem Areas and reducing test run below 20 min:
=== Feb 12 - Feb 17* Parallel testing by dividing the test suite into smaller groups that run concurrently across multiple CPU cores or machines, reducing the total CI/CD pipeline runtime
(Week 8 )* Write scripts that track codebase changes and trigger only the necessary tests based on dependencies, reducing redundant executions both in development and on the CI/CD pipeline
* Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance,
* Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected.Handling API rate limits and timeouts will be addressed by implementing throttling, rate-limiting, and retry mechanisms, such as exponential backoff, to minimize failures from API rate limits
=== Feb 26 - March 2Feb 5 - Feb 10 (Week 9)
(Week 9 )* Analyze previous work and incorporate feedback from the mentor
Run end to test to ensure E* Ensure all existing intermittentmodules are fully test failures are resolveded and cover all functionalities.
* Write a guide to assist developers in navigating and diagnosnew integration tests for new code and features, ensuring everything issues in failing testsworks as expected.
Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is from=== Feb 12 - Feb 17 (Week 10 )
=== March 4- March 9Stress Testing and End-to-End Testing:
(Week 10 )* Perform stress tests on each API endpoint to evaluate performance under load.
* Increase the JavaScript/JSX statement coverage to 90%
=== March 11- March 16* Use Capybara to conduct end-to-end tests, ensuring the server-rendered sections function properly across all system flows.
=== Feb 26 - March 2 (Week 121 )
*Continue monitoring the system platform to ensure all test pass properly and are effective and handle new codeFinal Testing and Documentation:
* Run end-to-end tests to ensure all intermittent test failures are resolved.
* Write a developer guide to assist in diagnosing issues in failing tests.
* Implement a user-friendly reporting strategy for error logs.
=== March 4- March 9 (Week 12 )
JavaScript Coverage Improvement:
* Increase JavaScript/JSX test coverage to 90%
=== March 11- March 16 (Week 13 )
Final Monitoring and Wrap-Up:
* Continue monitoring the system platform to ensure all tests pass and handle new code effectively.
* Wrap up the researchh and finalize the documentation.
C* Conduct code cleanupp in preparation for submission.
== Participation
I intend to use the project’s slack channel as the main communication channel and also through emails, as per the mentor’s convenience. I’ll equally github as the main means of contributing code where I will push commits to my own clone of the repository. I’ll be using GitHub’s issue tracker for feature requests and bugs and communicating through Phabricator task, I would equally help other contributors and users solve their issues and aid the process of reviewing my Pull request by writing good and understandable commit and pull request messages.
=About Me
== Education
I am a software engineering graduate from the University of Buea, set to graduate this December. During my studies, I gained proficiency in Python and Rust, test driven development, which enabled me have a strong knowledge software development. I was introduced to and began contributing to free and open-source software during my sophomore year, and I have continued ever since. The open-source community provides a collaborative and welcoming environment where I can practice and improve my skills without bias or limitations. I am particularly passionate about learning and ensuring that everyone has access to free, quality education. Contributing to Wikimedia and the Wiki Education Dashboard allows me to support this initiative in my own small way
== How did you hear about this program?
I learned about Outreachy from a mentor who has contributed to wikimedia through Outreachhy and GSOC over the years and suggested it was a great opportunity for me to learn and apply my skills in an industry project. I have applied to Outreachy for five times , the first two times I was accepted but didn't go pass the contribution phase and the last 3 I wasn't accepted.
== Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?
I have no other commitments as i am done with my degree program. I would like to spend time with my family from 24th of December to the 1st of January but I can accommodate any important task during this time.
== Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?
I don't have any other commitments, I don’t have any summer plan other than Outreachy. The Outreachy project phase takes the highest position on my priority list
== What does making this project happen mean to you?
I strongly believe in contributing in my own way to improve the challenges I have faced, enabling others to benefit from my experiences, my first PR to the platform ran for over 50 minutes and it failed. I struggled to understand the reason for the failure, as I did not clearly identify where the error originated and found it difficult to interpret the error messages. This process took me an entire day to resolve after seeking help from my mentors, Sageross and Abishecks, who were very approachable and provided valuable guidance. on what the issue was. Over the course of the development i have realized other contributors also have this challenge and for a newcomer it is very overwhelming, So improving the test suites of the dashboard will help improve the developer experience and help newcomers better understand the error they are having and what is the possible cause and how to fix them.
Furthermore, these improvements will enhance the overall performance of the dashboard, ensuring a seamless user experience and enabling students and instructors to maximize their use of the platform for education and knowledge transmission.
From a professional point of view, I have recently begun learning Ruby on Rails as part of my development skill set. Additionally, I am focused on writing comprehensive and efficient tests to improve system performance, maintainability, and scalability. I believe this project will allow me to apply my knowledge, enhance my skills as a tester, and contribute to significant FOSS projects while gaining direct access to mentorship.
== Past Experience
I am passionate about performant system that are maintainable and scalable, having been passionate about Software development since my second year in university since then I have been working continuously on personal projects and some open source projects. I have always been interested in building software that are reliable and has practical scale implications, and Open source has provided me with the platform to do so. I make commits with clean commit messages and well structured Pull Requests, I believe this helps me communicate my understanding of the task and help my mentors in the review process
= Coding Skills:
== Programming Languages and Frameworks:
Fluent in HTML, CSS, JavaScript, Ruby, Python
Proficient in Ruby on Rails and experienced with Django (Python) and Java.
Strong knowledge of OOP and MVC architecture.
Experienced with front-end frameworks such as React, Next.js, and Redux.
Proficient in testing tools: RSpec, Jest, and Capybara.
Familiar with CI/CD practices and tools.
Strong concepts of Git; can adapt to other version control tools if required.
Good analytical and problem-solving skills.
Effective communication skills for collaboration in a team.
Understanding of Agile methodologies
I have earned a great amount of experience with the codebase of the project. Also, I have made quite a few pull requests now and most of them have been merged. My contributions were focused towards writing unit test , fixing existing bugs,
Here is a list of my contributions:
== Wikimedia Contributions:
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5973
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5965
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5974
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5978
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5985
https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5986
= Other Contributions
== Unstructured Studio
https://github.com/unstructuredstudio/zubhub/pull/736
https://github.com/unstructuredstudio/zubhub/pull/778