Hi everyone,
I hope you are doing well.
I wanted to provide a brief update on my progress and ask for guidance
regarding my local setup while preparing to work on *FINERACT-2116*.
I am setting up Apache Fineract on *Windows 11*, using *VS Code*, with the
intention of contributing *E2E (Cucumber-based) tests* as part of my *GSoC
preparation*.
Progress so far
-
Successfully cloned the repository and set up the initial environment
-
Configured *Java 21*, as required by several Fineract modules
-
Resolved initial issues related to:
-
Java toolchain detection
-
spotlessJavaCheck failures (using spotlessApply)
-
The following command completes successfully:
gradlew build
Current blocker
When running:
gradlew -x test -x spotlessJavaCheck build
the build fails at the :fineract-war:war task due to a *Java version
mismatch*:
-
fineract-war expects *JVM runtime 17*
-
Several dependent modules (e.g. fineract-core, fineract-provider, etc.)
require *Java 21*
This results in a dependency resolution failure during the WAR build.
Request for guidance
I would appreciate advice on the following points:
-
What is the recommended Java version strategy for contributors working
on *E2E tests*?
-
Is there a recommended build command or profile where building the WAR
can be skipped for E2E-focused contributions?
-
Are there any Windows-specific considerations or documentation for this
workflow?
Additionally, from a *GSoC beginner perspective*, I would like to ask:
-
Would you recommend continuing with *FINERACT-2116*, or
-
Would it be more appropriate to switch to a more beginner-friendly issue
at this stage?
I am happy to adapt based on what would be most helpful for the project and
effective for learning the Fineract codebase.
Thank you very much for your time and guidance.
Kind regards,
Arnav Patil
On Fri, Dec 26, 2025 at 11:51 PM Ádám Sághy <[email protected]> wrote:
> 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]> 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
>>
>>
>
