Hi Aleks, Looks awesome, I'll take a look at the PR.
Best, Arnold On Mon, Mar 25, 2024 at 6:37 AM Aleksandar Vidakovic <al...@apache.org> wrote: > Hello everyone, > > ... as you know our integration tests are quite essential to ensure that > we are not breaking anything when we try to add new features or fix bugs. > Everyone who contributed to Fineract probably saw the integration tests or > even wrote one as part of their contribution. I guess you agree that > writing those integration tests - at least the way that it's currently done > - is a bit challenging. I'd even say that a bigger problem is to read them. > Even if you are the author then it's really difficult to understand (again) > the purpose and intention of those tests after some time has passed (read: > a year). > > The reasons for those difficulties (in my opinion) are: > > - we are writing handcrafted HTTP client code with help of the REST > Assured library to issue API requests against a running Fineract instance > - we do - again - manual JSON parsing... we do already a ton of manual > JSON parsing in Fineract itself, and now we do pretty much the same thing > again in the integration tests > - there is an "air gap" between the test code on the one side and the > actual business logic that gets executed which makes reading and reasoning > about those tests a lot more difficult than they should be (you need to run > a Fineract instance in debug mode, connect an IDE to the remote debug port, > set breakpoints, execute the integration tests...) > > I don't know what your preferences are, but personally I find tests a > valuable source of information when I try to understand a code base or > certain use case... next to any available documentation. Now, we know that > we are a bit thin on useful documentation at the moment (I hope this > changes...) which would mean that the only other source of dense > information are those hard to read/understand integration tests. > > This is why I'd like to propose a major improvement in that space: > > - use exclusively the Fineract Java API client to replace handcrafted > REST Assured code > - to a small extent we do this (use Fineract client) already, but it's > still not enough to improve the situation > - the use of Fineract client brings us type safety again and we don't > need to manually parse the JSON data (read: reduction of a ton of > boilerplate code) > - on top of this we should write the test specifications in Cucumber > /Gherkin (as we do already with our basic unit tests); these test specs are > easy to read (even for non-developers) and would allow a bigger audience to > contribute test cases > > Note: the "air gap" issue is not addressed by this proposal, but I think > these improvements are already significant enough. I have an idea for that > too, but this requires more changes that are backwards incompatible with > the current code base. > > I've created a pull request that shows how this could look like. Please > have a look at https://github.com/apache/fineract/pull/3821 and let me > know what you think. > > Cheers, > > Aleks >
