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
