Hi Adam, Thank you very much for the detailed explanation and for outlining the available testing approaches. This was extremely helpful.
I acknowledge Ahmed’s guidance on prioritizing the recent starter stories. However, after reviewing FINERACT-2116, I would like to proceed with this issue, as it aligns well with my current learning goals around testing and validation in Fineract. Based on your suggestions, I am inclined to start by exploring the *E2E (Cucumber-based) testing approach*, as it appears to be more readable and beginner-friendly, while still providing meaningful coverage. I will also review the referenced integration test (CreditBureauConfigurationTest) to better understand the existing patterns and helper methods. My plan is to: - Study the current Credit Bureau configuration flow and validations - Review existing E2E feature files and step definitions - Propose an initial E2E test structure for FINERACT-2116 and seek feedback before proceeding further Please let me know if this approach sounds reasonable, or if you would recommend starting differently. Thank you again for your guidance. Kind regards, Arnav Patil On Fri, Dec 19, 2025 at 2:28 PM Ádám Sághy <[email protected]> wrote: > Hi Arnav, > > > Welcome to the project! > > > I’ve had a look at this story, and while it doesn’t give us a ton of > details, Fineract has some testing strategies we can use: > > - *Unit testing:* This is usually for checking out small bits of logic > and calculations in the system. It might not be the best fit for this issue. > > - *Integration testing:* This helps make sure all the pieces work > together and communicate properly. Writing an integration test that calls > the right API and checks the validation logs and responses could be really > helpful! However, this kind of test in Fineract needs some developer > experience and knowledge of the existing helper methods for calling these > APIs. > > - *E2E testing:* Gherkin-based cucumber testing was introduced recently, > which is great because the test steps are written in plain English, making > them easier to understand and work with. > > > Here’s an example for each: > > > - *Integration test:* > `org.apache.fineract.integrationtests.CreditBureauConfigurationTest` > > - *E2E test:* `features/BusinessDate.feature:2` -> We don’t have any > existing E2E test cases for Credit Bureau testing, so we’ll need to create > the stepdefs, like > `org.apache.fineract.test.stepdef.common.BusinessDateStepDef#setIncorrectBusinessDateFailure`. > > > I hope this helps you get a better idea of the options available! > > > Regards, > > Adam > > > On Dec 19, 2025, at 6:26 AM, Arnav Patil <[email protected]> wrote: > > Hello everyone, > > My name is Arnav Patil, and I am a student preparing to contribute to > Apache Fineract as part of my GSoC preparation. > > I came across FINERACT-2116 (Create credit bureau configuration validation > tests) and wanted to check whether this issue is still relevant for the > current Fineract codebase. > > If so, I would like to work on it. I would also appreciate guidance on: > - Whether JUnit or Cucumber tests are preferred for this issue > - Any existing test classes or references I should follow > > Thank you for your time and guidance. > > Best regards, > Arnav Patil > >
