#4390 - CAS Manual Intervention (e2e tests)

[sh16011993]

As a part of this PR, the following e2e tests have been written:

• CASInvoiceAESTController(e2e)-updateInvoiceToResolved
  √ Should resolve an invoice in Manual intervention status for the provided invoice identifier.
  √ Should throw a HttpStatus Not Found (404) error when the CAS invoice to resolve doesn't exist.
  √ Should throw a HttpStatus Not Found (404) error when the CAS invoice to resolve does not have the expected Manual intervention status.
  √ Should throw a HttpStatus Forbidden (403) error when an unauthorized Ministry user tries to update the invoice.

• CASInvoiceAESTController(e2e)-getInvoices
  √ Should be able to get invoices for the first page in a paginated result with a limit of two per page with Manual intervention status in the descending order.
  √ Should throw a HttpStatus Bad Request (400) error when the invoice status is invalid.
  √ Should throw a HttpStatus Bad Request (400) error when the sortField is invalid.
  √ Should throw a HttpStatus Forbidden (403) error when an unauthorized Ministry user tries to get the invoices.

Screenshots for the above e2e test execution:

---

[andrewsignori-aot]

API executes the E2E tests concurrently and deleting the invoices can potentially impact other E2E tests files, unless I am missing something.
Am I missing something?

[sh16011993]

Adjusted as per our discussion on call.

[andrewsignori-aot]

Nice work, please take a look at the comments.

[andrewsignori-aot]

Since we are keeping it we can avoid the for as below, to avoid deleting the records from the DB one by one.

const invoiceIDsToDelete = invoicesToDelete.map((invoice) => invoice.id);
await db.casInvoiceDetail.delete({
  casInvoice: In(invoiceIDsToDelete),
});

[andrewsignori-aot]

A note for the future: unless required for the test, we can avoid creating more records than required. Here, one DisbursementValueType.BCGrant would be enough.

[dheepak-aot]

I see that CAS_INVOICE_STATUS_LAST_UPDATED_ON_END_DATE is not used in the data preparation but only in delete. In that case we can remove it.

[dheepak-aot]

I found later in the code that usage of add days with days added to fall between these days are used.

Alternatively faker.date.between() can be used to get a date randomly in the range.

Btw, the comment above and this is not a blocker.

[sh16011993]

I will leave it as discussed.

[andrewsignori-aot]

Nice work, thanks for doing the changes, only a few non-blocker comments. Looks good 👍

[dheepak-aot]

This assertion doesn't seem to be valid IMO.
An object return from find is checked for a property using it's own value.

I am even ok to check if it is some date.

[sh16011993]

I missed to remove it. I had added that for a totally different reason which got changed as a part of another review comment above. I will remove it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

E2E Workflow Workers Coverage Report

Totals
Statements:	65.95% ( 610 / 925 )
Methods:	60.36% ( 67 / 111 )
Lines:	68.99% ( 485 / 703 )
Branches:	52.25% ( 58 / 111 )

[github-actions]

Backend Unit Tests Coverage Report

Totals
Statements:	22.01% ( 3975 / 18063 )
Methods:	9.85% ( 228 / 2314 )
Lines:	25.4% ( 3437 / 13529 )
Branches:	13.96% ( 310 / 2220 )

[github-actions]

E2E Queue Consumers Coverage Report

Totals
Statements:	85.72% ( 1507 / 1758 )
Methods:	83.25% ( 169 / 203 )
Lines:	88.1% ( 1244 / 1412 )
Branches:	65.73% ( 94 / 143 )

[github-actions]

E2E SIMS API Coverage Report

Totals
Statements:	70.77% ( 6497 / 9181 )
Methods:	68.54% ( 806 / 1176 )
Lines:	74.32% ( 5049 / 6794 )
Branches:	53.01% ( 642 / 1211 )

[dheepak-aot]

Thanks for making the changes. Looks good. 👍