Building a Robust API with Integration Tests in Rust

This challenge focuses on strengthening a simple Rust web API by implementing comprehensive integration tests. You will learn to test the interactions between different parts of your application, ensuring that your API endpoints behave as expected under various conditions, including valid requests, invalid data, and potential error scenarios.

Problem Description

You've been provided with a basic Rust web API built using the actix-web framework. This API currently exposes two endpoints:

1. /items: A GET endpoint that returns a predefined list of items.
2. /items/{id}: A GET endpoint that returns a specific item by its ID.

Your task is to implement integration tests for this API. These tests should verify that:

• The /items endpoint correctly returns the entire list of items.
• The /items/{id} endpoint correctly retrieves an item when a valid ID is provided.
• The /items/{id} endpoint returns an appropriate error (e.g., 404 Not Found) when an invalid or non-existent ID is provided.
• The API gracefully handles requests with malformed input, if applicable (though this example focuses on path parameters).

You will need to set up a test environment that can spin up your actix-web application and make HTTP requests against it without needing to run a separate server process manually.

Key Requirements:

• Write integration tests in a separate file (e.g., tests/api.rs).
• Use a testing framework or library suitable for integration testing with actix-web. The actix-web::test module is highly recommended.
• Each test case should be well-defined and assert specific expected outcomes.
• Tests should cover both successful retrieval and error conditions.

Expected Behavior:

• A successful GET /items request should return a 200 OK status code and a JSON array of items.
• A successful GET /items/{id} request with a valid ID should return a 200 OK status code and the JSON representation of the specific item.
• A GET /items/{id} request with an invalid or non-existent ID should return a 404 Not Found status code.

Edge Cases to Consider:

• IDs that are not valid integers.
• IDs that exist but are at the boundaries of your data structure.
• An empty item list (though for this problem, the list is predefined and not empty).

Examples

Let's assume the predefined list of items is:

[
  {"id": 1, "name": "Laptop"},
  {"id": 2, "name": "Keyboard"},
  {"id": 3, "name": "Mouse"}
]

Example 1: Get All Items

• Input: GET /items
• Expected Output:
  • Status Code: 200 OK
  • Response Body (JSON):

    [
      {"id": 1, "name": "Laptop"},
      {"id": 2, "name": "Keyboard"},
      {"id": 3, "name": "Mouse"}
    ]
    

• Explanation: This test verifies that the /items endpoint correctly serves the entire collection of items.

Example 2: Get Specific Item (Valid ID)

• Input: GET /items/2
• Expected Output:
  • Status Code: 200 OK
  • Response Body (JSON):

    {"id": 2, "name": "Keyboard"}
    

• Explanation: This test checks if the /items/{id} endpoint can successfully retrieve an item based on its ID.

Example 3: Get Specific Item (Invalid ID)

• Input: GET /items/99
• Expected Output:
  • Status Code: 404 Not Found
  • Response Body (JSON): (The exact error message might vary, but a clear indication of "not found" is expected.)

    {"message": "Item not found"}
    

• Explanation: This test ensures that the API handles requests for non-existent items gracefully by returning a 404 status.

Constraints

• The core API logic (item data, serialization) should not be modified. You are only adding tests.
• The provided API structure uses actix-web.
• Tests should be written in Rust.
• No external HTTP clients should be used for testing; leverage actix-web's testing utilities.
• The solution should be self-contained within a single Rust project.

Notes

• You'll likely need to add actix-web as a dev-dependency in your Cargo.toml for testing purposes.
• Consider how to set up and tear down the actix-web application for each test or test suite. The actix_web::test::TestRequest and actix_web::test::init functions will be invaluable.
• Think about how to assert JSON responses. Libraries like serde_json might be helpful for comparing expected and actual JSON structures.
• Your tests should be independent of each other.