FINERACT-2793: migrate loan money movement tests to feign - #6355
Open
DeathGun44 wants to merge 15 commits into
Open
FINERACT-2793: migrate loan money movement tests to feign#6355DeathGun44 wants to merge 15 commits into
DeathGun44 wants to merge 15 commits into
Conversation
LoanTransactionAuditingIntegrationTest reverses a repayment as a second user to prove the audit fields record who made the change. Creating that user was the last thing in the file still going through REST Assured's UserHelper, and FeignUserHelper only knew how to build its own fixed non-bypass user. The generated UsersApi already exposes createUser; this just wraps it the way the rest of the helpers do, returning the full response so callers can read the generated id. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
…ts to feign These three already extended FeignLoanTestBase but kept a parallel REST Assured stack alive in @beforeeach: a RequestSpecification, a ResponseSpecification and a legacy LoanTransactionHelper built on top of them. Everything they called through that stack already had a typed equivalent on the base, so the stack goes and the call sites move over. Loan products now come from LoanProductTestBuilder.buildRequest() and loan applications from LoanRequestBuilders, so neither goes through JSON. Accounts move to the base's FeignAccountHelper and charge-off reason codes to FeignCodeHelper. The auditing test needs to reverse a repayment as a different user. FineractFeignClientHelper.createNewFineractFeignClient already builds a client for arbitrary credentials, so the second user gets its own FeignTransactionHelper instead of a second RequestSpecification. Its GET /internal/loan/{id}/transaction/{txId}/audit call stays on FeignRawHttpHelper: the internal resource carries no @operation or @apiresponse, so the endpoint is absent from the generated client. That is the existing documented acceptance in the raw-HTTP audit, not a new usage. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
…sement tests to feign Same shape as the previous commit: both classes already extended FeignLoanTestBase but kept a REST Assured stack for a legacy LoanTransactionHelper. Disbursements, repayments, loan reads, business dates and client creation all move to the base's typed equivalents, and the loan product and application are built with buildRequest() and LoanRequestBuilders. LoanAccountRepaymentCalculationTest also carried a JournalEntryHelper field that nothing referenced; it goes with the stack. The disbursement-before-submission case used a second LoanTransactionHelper wired to a 403 response spec and asserted on a parsed error list. It now asserts the status the response spec pinned, the globalisation code and the user message off CallFailedRuntimeException, so the expected 403 is still checked rather than being reduced to "something threw". Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
The last of the classes that extended FeignLoanTestBase while keeping a REST
Assured stack, and the one that leaned on it hardest: two LoanTransactionHelpers
(one wired to a 200 response spec, one to a bare spec for the error cases), an
AccountHelper, a JournalEntryHelper, and twelve reads that pulled single fields
out of the loan JSON by name.
Those reads are the bulk of the change. getLoanDetail(spec, spec, id, "summary")
followed by get("totalOutstanding") becomes
getLoanDetails(id).getSummary().getTotalOutstanding(), and the three status
constants the test carried ("active", "overpaid", "closedObligationsMet") were
only ever keys into that map, so they give way to LoanStatus and the base's
verifyLoanStatus.
Setting the product's penalty income account was a hand-built PUT through
Utils.performServerPut; PutLoanProductsProductIdRequest already models
incomeFromPenaltyAccountId, so it goes through updateLoanProduct instead.
loanChargePaidByList is a Set on the generated model and the server declares no
order for it, so the two-entry assertion now matches on sign rather than on
position. The original indexed get(0)/get(1) but then branched on the sign of
each, so it was already order-tolerant; this makes that explicit.
The three error cases used the second helper and asserted on a parsed error list.
They now assert the globalisation code off CallFailedRuntimeException.
installmentNumber was passed to every loanChargeRefund call and was null every
time, so the typed request omitting it sends the same body.
Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
A loan disbursement can be backed by post dated checks, but the disburse
request model had no field for them, so a test could only send them as
hand-written JSON. The template that lists the installments those checks
attach to, and the tranche amount the undo-last-disbursal response reports,
were missing for the same reason.
GET /loans/{loanId}/postdatedchecks/{installmentId} returns a single check
while declaring an array of them, so no generated client could deserialise
the reply. Correct the declared response and give the loan helper a typed
read of one check.
LoanReschedulingWithinCenterTest took its repayment strategy constant from
LoanApplicationTestBuilder. The identical constant on LoanProductTestBuilder
lets the migrated test drop its last import of the JSON builder.
Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
…ary tests to feign Covers the charge-off accounting scenarios, the paid-off loan charge refund, the last repayment details, the transaction summary totals and the blocked transactions on closed or overpaid loans. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
…o feign Covers the disbursal date validation, the undo of the last tranche of a multi-disbursement loan, the fixed principal percentage amortization schedules, the waive interest and write-off flow, and the repayment with post dated checks. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
…o feign Covers skipping a repayment falling on the first day of a month, the minimum days between disbursal and the first repayment, and the JLG loan schedule following a group meeting change. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
A group savings account can back a guarantee, but PostSavingsAccountsRequest only carried clientId even though the savings validator accepts groupId, so add it. Recovering guarantees was only reachable by loan external id; add the loan id form the tests need. The approval failures here return several validation codes at once, which the single-code helper on the base class cannot express, so the test reads every globalisation code out of the errors array. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
Several loan endpoints could not be driven from the generated client, so the
tests that exercise them had to hand-build JSON.
PostLoansLoanIdScheduleRequest was an empty class, so the variable installment
commands (calculateLoanSchedule, addVariations) had no body to send, and the
response carried no periods to read back. Add the exceptions the command
accepts and the schedule it answers with.
PUT /loans/{loanId}/disbursements/{disbursementId} declared no request body at
all, so the generated client took a bare String. Add the request the tranche
update accepts.
PostLoanProductsRequest was missing six fields the product create endpoint
accepts and validates: minimumGap and maximumGap, which a variable installment
product needs; syncExpectedWithDisbursementDate; and the three guarantee
percentages a hold-funds product needs. The loan product builder has a JSON
path and a typed path, and only the JSON one could send them, so a product
built the typed way came back without its configuration.
GetLoansLoanIdResponse.disbursementDetails was a Set even though the endpoint
answers an ordered array whose order carries meaning - tranches come back in
expected disbursement date order and callers read them by position. List is
what the neighbouring transactions and charges fields already use.
Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
The legacy VariableIntallmentsTransactionHelper is REST-assured and builds its term variations out of raw maps. Its Feign counterpart drives the same three commands through the loan rescheduling API, and the request builders make the distinction the two product types need explicit: a declining balance product drives the schedule by installmentAmount, a flat one by principal. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
…feign LoanDisbursementDetailsIntegrationTest (16 tests) and VariableInstallmentsIntegrationTest (13 tests) move onto the typed client. The disbursement detail test read its tranches out of a raw JSON array and formatted the dates back with SimpleDateFormat; it now reads the typed GetLoansLoanIdDisbursementDetails. Its three error paths assert the exact status and globalisation code instead of a ResponseSpecification. The variable installment test built every term variation as a nested HashMap across two near-identical helper classes. Both are now expressed through VariableInstallmentsRequestBuilders, which keeps the flat and declining balance variants apart. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
GroupSummaryReportsIntegrationTest was the last subclass of the RestAssured BaseLoanIntegrationTest, and it used nothing from it: the test builds its own request specification and only creates a group and runs three reports. What the inheritance did carry was two extensions, and neither has anything to do for this test. LoanTestLifecycleExtension closes every open loan in the database before and after each test, and the test creates no loans. ExternalEventsExtension snapshots the external event configuration and restores whatever the test changed, and the test changes none of it. Extending FeignIntegrationTest instead drops both. The reports are read with genericResultSet=false, the shape the test asserted on, so FeignReportHelper gains the row-array read next to the generic resultset one it already had. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
BaseLoanIntegrationTest has no subclasses left. It carried its own RestAssured request and response specifications, a LoanTransactionHelper and the loan domain constants, all of which the Feign loan tests now get from FeignLoanTestBase. Deleting it orphans two helpers that nothing else called, ExternalEventHelper and InlineLoanCOBHelper; both already have Feign counterparts in FeignExternalEventHelper and FeignCobHelper, so they go with it. Signed-off-by: DeathGun44 <krishnamewara841@gmail.com>
Contributor
Author
|
Correcting this schema shape triggers swagger-brake report R015. This is the intended and correct fix, as no generated client could read the old declared shape. (also mentioned in the jira ticket) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!
Your assigned reviewer(s) will follow our guidelines for code reviews.