Write Tests for the New API

[Tguntenaar]

Any changes made to the indexer should come with tests written as soon as #982 merges.

Is your feature request related to a problem? Please describe.

The current codebase lacks comprehensive test coverage, particularly for the new API endpoints and core functionality. While there is a basic test structure in place (as seen in src/tests.rs), it only tests the index route. This makes it difficult to ensure reliability and catch potential regressions when making changes.

Reference:

#[test]
fn test_index() {
    use rocket::local::blocking::Client;

    // Construct a client to use for dispatching requests.
    let client = Client::tracked(super::rocket()).expect("valid `Rocket`");

    // Dispatch a request to 'GET /' and validate the response.
    let response = client.get("/").dispatch();
    assert_eq!(response.into_string().unwrap(), "Welcome from fly.io!!!!!");
}

Describe the solution you'd like

We need to implement a comprehensive test suite that covers:

API Endpoints Testing:

• Proposal endpoints (reference: src/entrypoints/proposal/mod.rs)
• RFP endpoints (reference: src/entrypoints/rfp/mod.rs)
• Search functionality for both proposals and RFPs

Examples on endpoints we need to test:

• Search Proposals
• Get Proposals
• Get Proposal Snapshots
• Search RFPs
• Get RFPs
• Get RFP Snapshots

Database Operations:

• Test all DB operations in src/db/mod.rs
• Ensure proper handling of proposal and RFP snapshots
• Verify pagination and filtering logic

External Service Integration:

• Mock and test NearBlocks API client functionality
• Test RPC service interactions
• Verify proper error handling for external service failures

Background Services:

• Test the API background service functionality
• Verify proper cache invalidation
• Test the update mechanism for keeping data current

The tests should use the existing test infrastructure shown in the CI workflow.

Describe alternatives you've considered

1. Integration Tests Only: We could focus solely on integration tests that verify the entire system works together, but this would make it harder to isolate and fix issues.
2. Manual Testing: Continue with manual testing, but this isn't scalable and doesn't provide the confidence needed for continuous deployment.
3. Property-Based Testing: Implement property-based testing for complex data transformations, though this would require additional setup and complexity.

Additional context

• The project already has SQLx set up for database testing.
• The CI pipeline is configured to run tests in a PostgreSQL environment.
• We should consider using test fixtures for common data scenarios.
• Mock external services (NearBlocks API, RPC) to ensure tests are reliable and fast.

Key files to consider when implementing tests:

• src/tests.rs
• src/db/mod.rs
• src/entrypoints/proposal/mod.rs
• src/entrypoints/rfp/mod.rs

[ori-near]

@petersalomonsen @Tguntenaar as discussed on our call, can you please split this task up in the way that makes sense? Thanks.