Hi team, +1 for this FSIP initiative.
Looking at SonarQube, core modules such as fineract-charge,fineract-accounting and other modules currently show 0% coverage. I would like to contribute by writing Cucumber E2E and integration tests for *fineract-charge* to help establish its baseline. Is there a specific Jira epic or tracking issue logged for this FSIP effort where sub-tasks are being organized? Regards, Dhroov On Wed, Oct 28, 2026 at 12:18 PM Aman Mittal <[email protected]> wrote: > Hi James > > +1 for this FSIP, however i want to know how we will track the coverage > for Fineract. One thing we can rely on is to use sonarqube > https://sonarcloud.io/project/overview?id=apache_fineract (While it needs > configuring) it would be a good way to track the maintainability and > coverage overtime. Can we mandate coverage in the e2e coverage report or > perhaps utilize Codecov for new coverage? > > Regards > Aman > > On Wed, Oct 28, 2026 at 1:13 AM James Dailey <[email protected]> wrote: > >> Devs - >> >> As recently discussed on matrix >> https://matrix.to/#/#apache-fineract-dev:matrix.org >> >> We have a LOT of tests. Adam S. did much of the work to enable them to >> run in parallel on VMs. [1] [2], I believe alongside Kristoff. This >> enables them to run without bogging down. >> >> Yet, despite having something in the range of >1500 tests, we do not have >> good test coverages for large swaths of the project. It is HEAVILY skewed >> toward the Progressive Loan module. >> >> I would like to propose that a new FSIP (fineract significant improvement >> project) is discussed now, formulated, then voted upon in a week or two, >> then worked on by a range of folks over the next year. i.e. GSOC students, >> other volunteers, new devs, etc. We can certainly get some help from the >> AI tooling per previous discussions. Brainstorming time. >> >> AND, as a corollary, if we don't want to support an area of >> functionality, we should prune it from the code release. >> >> To put an arbitrary number to this: we need at least 40-50% coverage of >> an area of code to allow it to continue to be in the project. We want 70% >> coverage for some level of stability. We ramp this up on a quarterly >> reporting basis: >> >> 2027: >> * January 10th - what test coverage do we have today across the modules, >> assumed to be 0% for some modules, and up to 70% for others. Baseline >> published. >> * April 10th - at least 10% cucumber test coverage for all components >> that we intend to keep. Plans to prune begin. >> * July 10th - at least 20% cucumber test coverage for all components >> that we intend to keep. >> * Oct 10 - at least 40% . Pruning. >> * Jan 2028 - stability >> >> To work on something like this, you need to dig into the topic, examine >> the code, pay close attention to the existing cucumber tests and >> setup, write domain specific tests, and incrementally increase the test >> coverage. It must be coordinated and someone must own it - I would want an >> eager volunteer for this, just for the coordination. >> >> [1] >> https://github.com/apache/fineract/tree/develop/fineract-e2e-tests-runner/src/test/resources/features >> [2] (.github/workflows/build-e2e-tests.yml, scripts/split-features.sh, >> >> Comments, concerns, feedback? >> >> -James >> >>
