Aman-Mittal opened a new pull request, #676:
URL: https://github.com/apache/fineract-backoffice-ui/pull/676
Regression cover for #667, which withheld the loan **Repayment** button and
the savings **Deposit** and **Withdraw** buttons unless the record is in a
state the platform will act on.
That change landed with unit tests over a stubbed loan and account, and
**nothing against the platform that defines the rule**. Both are template
controls in heavily edited files; a future edit could reintroduce either defect
and every check would stay green.
## Two specs, each with two halves that fail for different reasons
**A walk through the states.** A loan awaiting approval offers no Repayment;
approved and awaiting disbursal, still none; active, it is back. A savings
account awaiting approval offers neither Deposit nor Withdraw; activated, both
return.
Each negative assertion is paired with a **control on the same screen** —
the Approve button — so a screen that simply failed to render cannot pass the
test. That is the trap a group-membership spec fell into earlier in this work:
the negative assertion passed because the tab was closed, not because the link
was withheld.
**A direct probe of the platform rule**, so the gate is pinned to the
behaviour it mirrors rather than to itself:
```
POST /loans/{id}/transactions?command=repayment
400 error.msg.loan.must.be.active.fully.paid.or.overpaid
POST /savingsaccounts/{id}/transactions?command=deposit
400 error.msg.savingsaccount.transaction.account.is.not.active
```
Without these, the specs would still pass if Fineract began accepting those
commands — at which point the gates would be wrong rather than right, and
nothing here would notice.
## Mutation tested before being trusted
Reintroducing each defect failed exactly the assertion that describes it:
| Defect reintroduced | Result |
|---|---|
| `@if (canAcceptRepayment)` removed |
`getByTestId('loan-repayment-action')` expected 0, received 1 |
| deposit/withdraw pulled out of `@if (isActive())` |
`getByTestId('savings-deposit-action')` expected 0, received 1 |
In both runs **the API probe kept passing while the UI assertion failed.**
That is the division of labour working as intended — a probe on its own would
have looked thorough and caught nothing.
Gates restored afterwards and the suite re-run green, so the committed tree
is the fixed one.
## Seeding
`seedSubmittedLoan` and `seedSubmittedSavingsAccount` stop before approval,
plus `approveLoan`, `disburseLoan` and `activateSavingsAccount` so a spec can
watch a record change state mid-test. `seedActiveLoan` and
`seedSavingsAccountWithTransactions` are rebuilt on them rather than
duplicating the application bodies.
One note recorded in `seedSubmittedSavingsAccount`: it seeds an **ordinary**
savings account deliberately. A fixed deposit in the same status answers a
different error from a different code path (`Fixed Depositaccount deposit
transaction not allowed`), which is a trap worth not rediscovering.
## Verification
```
npx playwright test --project=backend loan-repayment-gating
savings-transaction-gating
5 passed (44.6s)
npm run typecheck:e2e clean
prettier --check clean
```
`BACKEND_SPECS` gains both; the backend project goes from 119 tests to 123.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
