Files
finance/docs/db-integration-testing-plan.md
GitHub Copilot 07fbb82385 Fix: Update button remaining disabled in transaction edit mode
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.
2025-05-05 21:29:36 +00:00

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:

  1. PostgreSQL is running (via Docker or locally)
  2. Database migrations have been applied (npm run db:migrate -- --name initial)
  3. Seed data has been loaded (npm run db:seed)
  4. 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 studio to open the Prisma Studio interface
    • Verify you can view the database tables and data
  • Test Case 1.2: Check database tables creation

    • Verify accounts and transactions tables exist
    • Verify all columns match the schema definition
    • Check that proper indexes are created

2. Account Service Testing

  • Test Case 2.1: Get all accounts

    • Access /api/accounts endpoint
    • Verify it returns the seeded accounts with correct data
    • Check response format and status code (200)
  • 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-id endpoint
    • Verify it returns a 404 status code with appropriate error message

3. Transaction Service Testing

  • Test Case 3.1: Get account transactions

    • Get account ID from the list of accounts
    • Access /api/accounts/{id}/transactions endpoint
    • 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/transactions with 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)
  • 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)
  • 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)

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:

  1. API Tests: Use Vitest with Supertest to automate API endpoint testing
  2. Integration Tests: Use Vitest with JSDOM to test UI components with mocked API calls
  3. E2E Tests: Consider adding Playwright or Cypress for end-to-end testing

Reporting Issues

Document any issues found during testing with:

  1. Steps to reproduce
  2. Expected behavior
  3. Actual behavior
  4. Screenshots or console logs if applicable

Success Criteria

The database integration will be considered successfully tested when:

  1. All CRUD operations work correctly through both API and UI
  2. Account balances remain consistent with transactions
  3. Error handling works correctly for all error cases
  4. The application maintains performance under expected load