Hi I think your approach is okay.
Let us know if you are facing any issues! Regards, Adam > On Dec 20, 2025, at 8:45 AM, Arnav Patil <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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 >>
