Hi there, First and foremost, welcome! :)
It’s not easy to say, but our unit test coverage isn’t great. However, there’s a reason behind it: - Apache Fineract heavily relies on integration and end-to-end test coverage because it provides the most value in terms of covering expected behaviors. While there are certain logics, calculations, and other aspects that would benefit from proper unit testing, I don’t believe we have a comprehensive list of them or a gap analysis to identify areas for improvement. My recommendation is to review the existing modules and identify logics and calculations where unit testing would be beneficial. Some examples include: - Calculating interest - Calculating charges - Calculating due dates - Calculating balances - etc. I hope this provides some clarity and guidance. Regards, Adam > On Jul 5, 2026, at 12:11 PM, Hüseyin Berk Emir <[email protected]> > wrote: > > Subject: Ready for a new task — interested in unit testing > > Hello everyone, > > I'm Berk, a recent Computer Engineering graduate with a background in backend > development (Java/Spring Boot, C#/.NET). > > So far I've had two small refactors merged (FINERACT-2627 and FINERACT-2630, > both cleaning up Collection.isEmpty() usage), and I have a bug fix currently > under review in FINERACT-2622, which addresses ORDER BY preservation in > GenericDataServiceImpl.wrapSQL() on the reporting side. > > I'm now looking to pick up something new and would be glad to take on any > backend task you can point me to. That said, my main interest right now is > unit testing. In a recent internship I wrote 150+ NUnit/Moq unit tests on a > core banking platform, and I enjoyed how much it pushed me to understand the > underlying business logic rather than just the code. I'd love to bring that > into Fineract, both to help improve test coverage and as a way to learn the > banking/financial domain more deeply, which is an area I want to grow in. > > So if there are modules where more test coverage would be valuable, I'd be > happy to start there. But if a different bug or issue is a better fit for the > project's needs right now, I'm equally happy to take that on. Either way, I'd > appreciate a pointer to a good place to start — otherwise I'll look through > the open issues and propose something. > > Thanks for your time, and looking forward to contributing more. > > Best regards, > Hüseyin Berk Emir
