notid/integreat
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

feat(tests): implement integration and unit tests for auth, company, and ledger behaviors

Browse Source 
- Auth: 30 tests (97 assertions) covering OAuth, sessions, JWT, impersonation, roles
- Company: 35 tests (92 assertions) covering profile, 1099, expense reports, permissions
- Ledger: 113 tests (148 assertions) covering grid, journal entries, import, reports
- Fix existing test failures in running_balance, insights, tx, plaid, graphql
- Fix InMemSolrClient to handle Solr query syntax properly
- Update behavior docs: auth (42 done), company (32 done), ledger (120 done)
- All 478 tests pass with 0 failures, 0 errors
This commit is contained in:
Bryce
2026-05-08 16:12:08 -07:00
parent d9d9263824
commit 6b5d33a32f
64 changed files with 9005 additions and 2086 deletions
Download Patch File Download Diff File Expand all files Collapse all files

152
docs/testing/behaviors/payment.md
View File

@@ -51,7 +51,7 @@ Check printing involves:
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 1.1 | It should display a table with columns: Client, Vendor, Bank Account, Check #, Status, Date, Amount, Links | UI | [ ] |
| 1.2 | It should show the Client column only when viewing payments for multiple clients | Integration | [ ] |
| 1.2 | It should show the Client column only when viewing payments for multiple clients | Integration | SKIPPED |
| 1.3 | It should hide the Bank Account and Date columns on smaller viewports | UI | [ ] |
| 1.4 | It should show "Cleared" status as a primary-colored pill | UI | [ ] |
| 1.5 | It should show "Pending" status as a secondary-colored pill | UI | [ ] |
@@ -66,41 +66,41 @@ Check printing involves:
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 2.1 | It should filter payments by vendor typeahead selection | Integration | [ ] |
| 2.2 | It should filter payments by date range | Integration | [ ] |
| 2.3 | It should filter payments by check number (exact match or partial text) | Integration | [ ] |
| 2.4 | It should filter payments by invoice number (exact match) | Integration | [ ] |
| 2.5 | It should filter payments by amount range (min/max) | Integration | [ ] |
| 2.6 | It should filter payments by payment type via radio cards (All, Cash, Check, Debit) | Integration | [ ] |
| 2.7 | It should support exact-match navigation to a specific payment by ID, bypassing other filters | Integration | [ ] |
| 2.8 | It should filter payments by status via route (`/payments/pending`, `/payments/cleared`, `/payments/voided`) | Integration | [ ] |
| 2.9 | It should apply all filters via HTMX with debounced triggers | Integration | [ ] |
| 2.10 | It should combine all filters with AND logic | Integration | [ ] |
| 2.11 | It should use efficient time-bounded queries for date range filtering | Integration | [ ] |
| 2.12 | It should parse check number search as Long when possible, falling back to exact string match | Unit + Integration | [ ] |
| 2.13 | Given multiple filters are applied, when the user changes one filter, then the table should refresh with the combined filter set | Integration | [ ] |
| 2.14 | It should bypass all other filters when exact-match ID is provided | Integration | [ ] |
| 2.1 | It should filter payments by vendor typeahead selection | Integration | [x] |
| 2.2 | It should filter payments by date range | Integration | [x] |
| 2.3 | It should filter payments by check number (exact match or partial text) | Integration | [x] |
| 2.4 | It should filter payments by invoice number (exact match) | Integration | [x] |
| 2.5 | It should filter payments by amount range (min/max) | Integration | [x] |
| 2.6 | It should filter payments by payment type via radio cards (All, Cash, Check, Debit) | Integration | [x] |
| 2.7 | It should support exact-match navigation to a specific payment by ID, bypassing other filters | Integration | [x] |
| 2.8 | It should filter payments by status via route (`/payments/pending`, `/payments/cleared`, `/payments/voided`) | Integration | [x] |
| 2.9 | It should apply all filters via HTMX with debounced triggers | Integration | SKIPPED |
| 2.10 | It should combine all filters with AND logic | Integration | [x] |
| 2.11 | It should use efficient time-bounded queries for date range filtering | Integration | SKIPPED |
| 2.12 | It should parse check number search as Long when possible, falling back to exact string match | Unit + Integration | [x] |
| 2.13 | Given multiple filters are applied, when the user changes one filter, then the table should refresh with the combined filter set | Integration | [x] |
| 2.14 | It should bypass all other filters when exact-match ID is provided | Integration | [x] |
### Sorting Behaviors
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 3.1 | It should sort by client name ascending/descending | Integration | [ ] |
| 3.2 | It should sort by vendor name ascending/descending | Integration | [ ] |
| 3.3 | It should sort by bank account ascending/descending | Integration | [ ] |
| 3.4 | It should sort by check number ascending/descending | Integration | [ ] |
| 3.5 | It should sort by date ascending/descending | Integration | [ ] |
| 3.6 | It should sort by amount ascending/descending | Integration | [ ] |
| 3.7 | It should sort by status ascending/descending | Integration | [ ] |
| 3.8 | Given the user clicks a column header twice, then the sort direction should toggle | Integration | [ ] |
| 3.1 | It should sort by client name ascending/descending | Integration | [x] |
| 3.2 | It should sort by vendor name ascending/descending | Integration | [x] |
| 3.3 | It should sort by bank account ascending/descending | Integration | [x] |
| 3.4 | It should sort by check number ascending/descending | Integration | [x] |
| 3.5 | It should sort by date ascending/descending | Integration | [x] |
| 3.6 | It should sort by amount ascending/descending | Integration | [x] |
| 3.7 | It should sort by status ascending/descending | Integration | [x] |
| 3.8 | Given the user clicks a column header twice, then the sort direction should toggle | Integration | [x] |
### Pagination Behaviors
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 4.1 | It should display 25 payments per page by default | Integration | [ ] |
| 4.2 | It should allow changing the per-page count | Integration | [ ] |
| 4.3 | It should calculate the total visible float and total float across all matching payments, not just the current page | Unit | [ ] |
| 4.1 | It should display 25 payments per page by default | Integration | [x] |
| 4.2 | It should allow changing the per-page count | Integration | [x] |
| 4.3 | It should calculate the total visible float and total float across all matching payments, not just the current page | Unit | [x] |
### Selection Behaviors
@@ -108,8 +108,8 @@ Check printing involves:
|---|----------|---------------|--------|
| 5.1 | It should allow selecting individual payments via checkboxes | UI | [ ] |
| 5.2 | It should allow selecting all visible payments via a header checkbox | UI | [ ] |
| 5.3 | It should allow selecting all filtered payments (up to 250) for bulk operations | Integration | [ ] |
| 5.4 | Given payments are selected, when the user applies a filter, then the selection should be cleared | Integration | [ ] |
| 5.3 | It should allow selecting all filtered payments (up to 250) for bulk operations | Integration | SKIPPED |
| 5.4 | Given payments are selected, when the user applies a filter, then the selection should be cleared | Integration | SKIPPED |
### Row Action Behaviors
@@ -118,16 +118,16 @@ Check printing involves:
| 6.1 | It should show a trash icon on each row unless the payment status is already voided | UI | [ ] |
| 6.2 | It should prompt for confirmation when clicking the trash icon ("Are you sure you want to void this payment?") | UI | [ ] |
| 6.3 | Given confirmation, when voiding a payment, then the row should be removed from the table with animation | UI | [ ] |
| 6.4 | It should block voiding cleared check payments | Integration | [ ] |
| 6.4 | It should block voiding cleared check payments | Integration | [x] |
### Float Display Behaviors
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 7.1 | It should display a "Visible in float" pill showing the sum of pending payment amounts in the current filter view | Unit | [ ] |
| 7.2 | It should display a "Total in float" pill showing the sum of all pending payments for the selected client(s) | Unit | [ ] |
| 7.3 | It should exclude voided payments from float calculations | Unit | [ ] |
| 7.4 | It should include only pending status payments in float calculations | Unit | [ ] |
| 7.1 | It should display a "Visible in float" pill showing the sum of pending payment amounts in the current filter view | Unit | [x] |
| 7.2 | It should display a "Total in float" pill showing the sum of all pending payments for the selected client(s) | Unit | [x] |
| 7.3 | It should exclude voided payments from float calculations | Unit | [x] |
| 7.4 | It should include only pending status payments in float calculations | Unit | [x] |
---
@@ -137,10 +137,10 @@ Check printing involves:
|---|----------|---------------|--------|
| 8.1 | It should show a confirmation modal with warning icon and count of payments to be voided | UI | [ ] |
| 8.2 | It should support "Selected only" mode to void only checkboxed payments | UI | [ ] |
| 8.3 | It should support "All selected" mode to void all payments matching current filters (up to 250) | Integration | [ ] |
| 8.4 | It should require admin permission for bulk void operations | Integration | [ ] |
| 8.5 | Given confirmation, when voiding, then the modal should close and a notification should show "Successfully voided X of Y payments" | Integration | [ ] |
| 8.6 | It should skip payments that already have transactions and skip already-voided payments | Integration | [ ] |
| 8.3 | It should support "All selected" mode to void all payments matching current filters (up to 250) | Integration | [x] |
| 8.4 | It should require admin permission for bulk void operations | Integration | [x] |
| 8.5 | Given confirmation, when voiding, then the modal should close and a notification should show "Successfully voided X of Y payments" | Integration | SKIPPED |
| 8.6 | It should skip payments that already have transactions and skip already-voided payments | Integration | [x] |
---
@@ -148,17 +148,17 @@ Check printing involves:
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 9.1 | It should generate physical check PDFs with MICR encoding at the bottom | Integration | [ ] |
| 9.2 | It should include payee, amount in numbers and words, date, memo, bank info, and client signature image | Integration | [ ] |
| 9.3 | It should generate voucher copies with full invoice details below the check | Integration | [ ] |
| 9.4 | It should store check PDFs in S3 under `checks/{uuid}.pdf` | Integration | [ ] |
| 9.5 | It should assign check numbers sequentially from the bank account's check number | Integration | [ ] |
| 9.6 | It should increment the bank account's check number by the number of vendors paid | Integration | [ ] |
| 9.7 | It should validate that the bank account has a starting check number | Integration | [ ] |
| 9.8 | It should merge multiple checks into a single PDF at `merged-checks/{uuid}.pdf` | Integration | [ ] |
| 9.9 | It should group invoices by vendor, creating one check per vendor per batch | Integration | [ ] |
| 9.10 | It should validate that all invoices belong to the same client and the selected bank account belongs to the same client | Integration | [ ] |
| 9.11 | It should reject check creation if the total amount is <= $0.00 | Integration | [ ] |
| 9.1 | It should generate physical check PDFs with MICR encoding at the bottom | Integration | SKIPPED |
| 9.2 | It should include payee, amount in numbers and words, date, memo, bank info, and client signature image | Integration | SKIPPED |
| 9.3 | It should generate voucher copies with full invoice details below the check | Integration | SKIPPED |
| 9.4 | It should store check PDFs in S3 under `checks/{uuid}.pdf` | Integration | SKIPPED |
| 9.5 | It should assign check numbers sequentially from the bank account's check number | Integration | [x] |
| 9.6 | It should increment the bank account's check number by the number of vendors paid | Integration | [x] |
| 9.7 | It should validate that the bank account has a starting check number | Integration | [x] |
| 9.8 | It should merge multiple checks into a single PDF at `merged-checks/{uuid}.pdf` | Integration | SKIPPED |
| 9.9 | It should group invoices by vendor, creating one check per vendor per batch | Integration | [x] |
| 9.10 | It should validate that all invoices belong to the same client and the selected bank account belongs to the same client | Integration | [x] |
| 9.11 | It should reject check creation if the total amount is <= $0.00 | Integration | [x] |
---
@@ -166,9 +166,9 @@ Check printing involves:
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 10.1 | It should create pending payments with `payment-type/debit` | Integration | [ ] |
| 10.2 | It should not generate check PDFs for ACH payments | Integration | [ ] |
| 10.3 | It should not create transactions for ACH payments | Integration | [ ] |
| 10.1 | It should create pending payments with `payment-type/debit` | Integration | [x] |
| 10.2 | It should not generate check PDFs for ACH payments | Integration | [x] |
| 10.3 | It should not create transactions for ACH payments | Integration | [x] |
---
@@ -176,10 +176,10 @@ Check printing involves:
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 11.1 | It should allow paying invoices from existing vendor credit with `payment-type/balance-credit` | Integration | [ ] |
| 11.2 | It should block balance credit payments when multiple vendors are selected | Integration | [ ] |
| 11.3 | It should offset positive-balance invoices against negative-balance invoices | Integration | [ ] |
| 11.4 | It should create a single cleared payment for the net amount, consuming credit invoices first-in | Integration | [ ] |
| 11.1 | It should allow paying invoices from existing vendor credit with `payment-type/balance-credit` | Integration | [x] |
| 11.2 | It should block balance credit payments when multiple vendors are selected | Integration | [x] |
| 11.3 | It should offset positive-balance invoices against negative-balance invoices | Integration | [x] |
| 11.4 | It should create a single cleared payment for the net amount, consuming credit invoices first-in | Integration | [x] |
---
@@ -187,10 +187,10 @@ Check printing involves:
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 12.1 | It should create payments with `payment-type/cash` automatically marked as cleared | Integration | [ ] |
| 12.2 | It should create an associated transaction with POSTED status | Integration | [ ] |
| 12.3 | It should use the account with numeric code 21000 for cash payment transactions | Integration | [ ] |
| 12.4 | It should set the payment date to the latest invoice date | Integration | [ ] |
| 12.1 | It should create payments with `payment-type/cash` automatically marked as cleared | Integration | [x] |
| 12.2 | It should create an associated transaction with POSTED status | Integration | [x] |
| 12.3 | It should use the account with numeric code 21000 for cash payment transactions | Integration | [x] |
| 12.4 | It should set the payment date to the latest invoice date | Integration | [x] |
---
@@ -200,33 +200,33 @@ Check printing involves:
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 13.1 | It should allow voiding pending payments | Integration | [ ] |
| 13.2 | It should allow voiding cash, debit, and balance-credit payments even when cleared | Integration | [ ] |
| 13.3 | It should block voiding cleared check payments | Integration | [ ] |
| 13.4 | It should set the payment amount to 0.0 when voided | Integration | [ ] |
| 13.5 | It should set the payment status to voided | Integration | [ ] |
| 13.6 | It should remove all invoice-payment links when voiding | Integration | [ ] |
| 13.7 | It should restore invoice outstanding balances by adding back the invoice-payment amount | Integration | [ ] |
| 13.8 | It should revert invoice status to unpaid when restored balance becomes non-zero | Integration | [ ] |
| 13.9 | It should unlink associated transactions when voiding | Integration | [ ] |
| 13.1 | It should allow voiding pending payments | Integration | [x] |
| 13.2 | It should allow voiding cash, debit, and balance-credit payments even when cleared | Integration | [x] |
| 13.3 | It should block voiding cleared check payments | Integration | [x] |
| 13.4 | It should set the payment amount to 0.0 when voided | Integration | [x] |
| 13.5 | It should set the payment status to voided | Integration | [x] |
| 13.6 | It should remove all invoice-payment links when voiding | Integration | [x] |
| 13.7 | It should restore invoice outstanding balances by adding back the invoice-payment amount | Integration | [x] |
| 13.8 | It should revert invoice status to unpaid when restored balance becomes non-zero | Integration | [x] |
| 13.9 | It should unlink associated transactions when voiding | Integration | [x] |
### Permission Behaviors
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 14.1 | It should require client visibility for viewing payments | Integration | [ ] |
| 14.2 | It should require client visibility for voiding individual payments | Integration | [ ] |
| 14.3 | It should require admin permission for bulk voiding payments | Integration | [ ] |
| 14.4 | It should allow viewing S3 check PDFs to all users who can see the payment | Integration | [ ] |
| 14.1 | It should require client visibility for viewing payments | Integration | [x] |
| 14.2 | It should require client visibility for voiding individual payments | Integration | [x] |
| 14.3 | It should require admin permission for bulk voiding payments | Integration | [x] |
| 14.4 | It should allow viewing S3 check PDFs to all users who can see the payment | Integration | SKIPPED |
### Lock Date Behaviors
| # | Behavior | Test Strategy | Status |
|---|----------|---------------|--------|
| 15.1 | It should block voiding payments dated before the client's locked-until date | Integration | [ ] |
| 15.2 | It should check lock dates on individual void operations | Integration | [ ] |
| 15.3 | It should check lock dates on bulk void operations | Integration | [ ] |
| 15.4 | It should exclude locked payments from bulk void results | Integration | [ ] |
| 15.1 | It should block voiding payments dated before the client's locked-until date | Integration | [x] |
| 15.2 | It should check lock dates on individual void operations | Integration | [x] |
| 15.3 | It should check lock dates on bulk void operations | Integration | [x] |
| 15.4 | It should exclude locked payments from bulk void results | Integration | [x] |
| 15.5 | It should show a warning when some selected payments are locked | UI | [ ] |
---