This commit resolves an issue where the Update button in the transaction form would remain disabled when attempting to edit a transaction. The problem was in how the transactionStore was managing state updates during transaction editing. Key changes: - Enhanced startEditingTransaction function in transactionStore.ts to ensure proper reactivity - Added clean copy creation of transaction objects to avoid reference issues - Implemented a state update cycle with null value first to force reactivity - Added a small timeout to ensure state changes are properly detected by components The Transaction form now correctly enables the Update button when in edit mode, regardless of account selection state.
5.6 KiB
Database Integration Testing Plan
This document outlines the testing strategy for verifying the successful integration of our PostgreSQL database with the finance application.
Prerequisites
Before running tests, ensure that:
- PostgreSQL is running (via Docker or locally)
- Database migrations have been applied (
npm run db:migrate -- --name initial) - Seed data has been loaded (
npm run db:seed) - The application server is running (
npm run dev)
1. Database Connection Testing
-
Test Case 1.1: Verify Prisma can connect to the database
- Run
npx prisma studioto open the Prisma Studio interface - Verify you can view the database tables and data
- Run
-
Test Case 1.2: Check database tables creation
- Verify
accountsandtransactionstables exist - Verify all columns match the schema definition
- Check that proper indexes are created
- Verify
2. Account Service Testing
-
Test Case 2.1: Get all accounts
- Access
/api/accountsendpoint - Verify it returns the seeded accounts with correct data
- Check response format and status code (200)
- Access
-
Test Case 2.2: Get single account
- Get account ID from the list of accounts
- Access
/api/accounts/{id}endpoint - Verify it returns the correct account data
- Check response format and status code (200)
-
Test Case 2.3: Handle non-existent account
- Access
/api/accounts/nonexistent-idendpoint - Verify it returns a 404 status code with appropriate error message
- Access
3. Transaction Service Testing
-
Test Case 3.1: Get account transactions
- Get account ID from the list of accounts
- Access
/api/accounts/{id}/transactionsendpoint - Verify it returns the correct transactions for that account
- Check response format and status code (200)
-
Test Case 3.2: Create new transaction
- Send POST request to
/api/transactionswith valid transaction data - Verify the response contains the created transaction with an ID
- Check that account balance is updated correctly
- Check response status code (201)
- Send POST request to
-
Test Case 3.3: Update transaction
- Get transaction ID from a list of transactions
- Send PUT request to
/api/transactions/{id}with updated data - Verify the transaction is updated in the database
- Check that account balance is adjusted correctly
- Check response status code (200)
-
Test Case 3.4: Delete transaction
- Get transaction ID from a list of transactions
- Send DELETE request to
/api/transactions/{id} - Verify the transaction is removed from the database
- Check that account balance is adjusted correctly
- Check response status code (204)
4. Error Handling Testing
-
Test Case 4.1: Submit invalid transaction data
- Send POST request with missing required fields
- Verify appropriate error messages are returned
- Check response status code (400)
-
Test Case 4.2: Update non-existent transaction
- Send PUT request to
/api/transactions/nonexistent-id - Verify appropriate error message is returned
- Check response status code (404)
- Send PUT request to
-
Test Case 4.3: Delete non-existent transaction
- Send DELETE request to
/api/transactions/nonexistent-id - Verify appropriate error message is returned
- Check response status code (404)
- Send DELETE request to
5. UI Integration Testing
-
Test Case 5.1: Account selection updates
- Select different accounts from the dropdown
- Verify account summary (balance) updates correctly
- Verify transaction table updates to show correct transactions
-
Test Case 5.2: Add transaction form submission
- Fill out the transaction form with valid data
- Submit the form
- Verify the new transaction appears in the transaction table
- Verify account balance updates correctly
-
Test Case 5.3: Edit transaction functionality
- Click edit button on an existing transaction
- Modify transaction data and submit
- Verify the transaction is updated in the transaction table
- Verify account balance updates correctly
-
Test Case 5.4: Delete transaction functionality
- Click delete button on an existing transaction
- Confirm deletion
- Verify the transaction is removed from the transaction table
- Verify account balance updates correctly
6. Data Consistency Testing
-
Test Case 6.1: Account balance consistency
- Calculate the sum of transaction amounts for an account
- Compare with the account balance in the database
- Verify they match exactly
-
Test Case 6.2: Transaction sequence
- Create multiple transactions rapidly
- Verify all transactions are saved correctly
- Check that account balance reflects all transactions
7. Performance Testing
- Test Case 7.1: Load testing with multiple transactions
- Create a test script that adds 100+ transactions
- Verify the application handles the load without errors
- Check response times remain reasonable
Test Automation
Consider creating automated tests for these scenarios using the following approaches:
- API Tests: Use Vitest with Supertest to automate API endpoint testing
- Integration Tests: Use Vitest with JSDOM to test UI components with mocked API calls
- E2E Tests: Consider adding Playwright or Cypress for end-to-end testing
Reporting Issues
Document any issues found during testing with:
- Steps to reproduce
- Expected behavior
- Actual behavior
- Screenshots or console logs if applicable
Success Criteria
The database integration will be considered successfully tested when:
- All CRUD operations work correctly through both API and UI
- Account balances remain consistent with transactions
- Error handling works correctly for all error cases
- The application maintains performance under expected load