[
https://issues.apache.org/jira/browse/FINERACT-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109702#comment-18109702
]
Dhananjay Bhagat edited comment on FINERACT-2165 at 8/30/26 4:40 PM:
---------------------------------------------------------------------
Hi [~adamsaghy], I am working on migrating *ShareAccountChargeRoundingTest* as
part of this ticket and while doing so I noticed an issue with the Swagger
model for *PostAccountsTypeAccountIdRequest* where the field *requestedShares*
can represent different request payloads depending on the command being used.
In particular, it can represent:
* a number of shares, e.g. *100*
* a collection of transaction IDs, represented as objects containing an
{*}id{*}, e.g. *[\{"id": 35}]*
Currently, the Swagger model represents *requestedShares* as a
{*}Set<PostAccountsRequestedShares>{*}, which does not cover the case where the
value is a {*}number{*}.
Since the same property can therefore have these different forms, what would be
the preferred way to describe *requestedShares* in the Swagger/OpenAPI schema
so that the generated client correctly represents both cases?
was (Author: JIRAUSER312255):
Hi [~adamsaghy], I am working on migrating *ShareAccountChargeRoundingTest* as
part of this ticket and while doing so I noticed an issue with the Swagger
model for *PostAccountsTypeAccountIdRequest* where the field *requestedShares*
can represent different request payloads depending on the command being used.
In particular, it can represent:
* a number of shares, e.g. *100*
* a collection of transaction IDs, represented as objects containing an
{*}id{*}, e.g. *[\{"id": 35}]*
Currently, the Swagger model represents *requestedShares* as a
{*}Set<PostAccountsRequestedShares>{*}, which does not cover the case where the
value is a {*}number{*}.
Since the same property can therefore have these different forms, what would be
the preferred way to describe *requestedShares* in the Swagger/OpenAPI schema
so that the generated client correctly represents both cases?
> Use "Fineract-client-feign" in integration tests
> ------------------------------------------------
>
> Key: FINERACT-2165
> URL: https://issues.apache.org/jira/browse/FINERACT-2165
> Project: Apache Fineract
> Issue Type: Improvement
> Affects Versions: 1.11.0
> Reporter: Adam Saghy
> Assignee: Adam Saghy
> Priority: Major
> Labels: beginner, beginner-friendly, code-debt, improvement,
> newjoiner-safe
>
> `Fineract-client` was introduced as part of
> https://issues.apache.org/jira/browse/FINERACT-1189 and some integration
> tests were using it (https://issues.apache.org/jira/browse/FINERACT-1209) but
> unfortunately many were not used and new integration tests got implemented
> but still not using the `fineract-client`!
> Since then a new variant was introduced:
> *[FINERACT-2380|https://issues.apache.org/jira/browse/FINERACT-2380]: create
> feign client*
>
> *Why Fineract-client-feign is better?*
> * Type safety comes out of box!
> ** Type safe requests, and responses!
> * No need to "fabricate" the endpoints!
> * We can move away from the RequestSpecification and ResponseSpecification
> configurations!
> * Fineract-client is automatically generated based on the swagger
> configuration / request / response object!
> *Why would it be beneficial to rewrite our integration tests?*
> * No more struggling with Map<String, Object>-s to fabricate request objects
> and trying to fetch out fields from response Object / Map...
> * No more GSON conversion back and forth
> * No more "is this json string contains XYZ?"
> ** Mostly was done to test exception messages...
> * No more N+1 method with slightly different parameter list
> * *Fineract-client got tested more thoroughly!*
> * *Our swagger configurations got tested more thoroughly!*
> * *Better maintainability!*
> * *Better readability!*
> * *Less error-prone!*
> I would like to give it a try as part of this story!
> # step: Marking all the methods as *deprecated* in the Helper classes which
> were using Rest-Assured for communicating with the backend!
> # step: Inform the Fineract-Dev mail list to not use "RestAssured based"
> solutions for any of the newly created integration tests!
> # step: Ask the community to start using the `fineract-client` based
> communication for all the newly created integration tests!
> ## Check in the helper classes whether for the required action there is a
> "Fineract-client based" implementation
> ## *If yes, please use that!*
> ## *If no, please implement it!*
> ### If it is broken, example: swagger request or response is not complete ->
> there is a missing field or the data type is incorrect -> *Please fix it!*
> # step: Ask the community and the newcomers to start removing the methods
> that were marked as *deprecated* and rewrite them to use *`fineract-client`
> instead!*
> ## *This means the integration tests that were using the deprecated methods
> must also be changed!*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
