The backend application incorporates automated testing using pytest with a focus on API integration tests. The test suite, amassing 23 tests in total, validates both database interactions and API functionality through the HTTP layer. All of these tests pass as demonstrated in the screenshot below:

Unit Tests

Our unit tests focus on validating individual components and functions. In most cases these are either utility function or service class functions. An example of a unit test is demonstrated below:

async def test_api_key_hashing():
    """Test that API key hashing is consistent."""
    api_key = generate_api_key()
    hashed_key = hash_api_key(api_key)
    
    assert hash_api_key(api_key) == hashed_key
    
    different_key = generate_api_key()
    assert hash_api_key(different_key) != hashed_key

This function validates the api key hashing system which is a single unit of code that is incorporated into our API.

Integration Tests

Integration tests verify the interaction between components and validate the API. These are used to validate a complete flow of data from source to destination, triggering operations between components, simulating real API requests and behaviour that occurs during them. Most of the integration tests we have are tests specific for certain API endpoints that test interaction between multiple schemas. An example of such a test is shown in the snippet below:

async def test_create_location(client: AsyncClient, seed_data_layer: Dict):
    """Test creating a new location."""
    location_data = {
        "bottom_left_latitude": 51.5074,
        "bottom_left_longitude": -0.1278,
        "top_right_latitude": 51.5084,
        "top_right_longitude": -0.1268,
        "resolution": 0.5,
        "reliability_score": 0.9,
        "layers": ["test_layer"],
    }

    response = await client.post("/v1/locations/", json=location_data)

    assert response.status_code == 201
    data = response.json()
    assert "id" in data
    assert data["bottom_left_latitude"] == 51.5074
    assert data["bottom_left_longitude"] == -0.1278

This test uses the separate client used just for testing in order to invoke an api request to create a location, which in turn interacts with the database. The output is then validated, hence testing the whole flow from request to database and back.

Components Tested

Below is a summary of the components that were tested and specific test cases for each:

Test Isolation with Docker

The test suite utilizes Docker to run the tests in complete isolation. A separate Docker container is created where all the tests run, then is detached. Below is the snippet of code that implements the containerisation:

@pytest.fixture(scope="session", autouse=USE_DOCKER_FOR_TESTS)
def setup_docker():
    """Set up a Docker container for PostgreSQL if needed."""
    container_name = "postgres-test"
    
    # Start PostgreSQL container
    subprocess.run([
        "docker", "run", "--name", container_name,
        "-e", f"POSTGRES_PASSWORD={TEST_DB_PASSWORD}",
        "-e", f"POSTGRES_USER={TEST_DB_USER}",
        "-e", f"POSTGRES_DB={TEST_DB_NAME}",
        "-p", f"{TEST_DB_PORT}:5432", "-d", "postgres:13"
    ], check=True)
    
    # Wait for PostgreSQL to start accepting connections
    # ...
    
    yield
    
    # Clean up after tests
    subprocess.run(["docker", "rm", "-f", container_name], check=True)

Running Tests

Tests can be run using the Makefile command:

make test

For Docker-based testing (recommended for complete isolation):

export USE_DOCKER_FOR_TESTS=true
make test

This will:

1. Start a dedicated PostgreSQL container for testing
2. Run all tests against this isolated database
3. Remove the test container when testing is complete

Feedback Summary

• Feedback 1: Summary from testers

We got very good feedback from our testers. Even when asked to be very critical, the testers gave our design an average score of 8.2 / 10. Furthermore, most of the members of the visually impaired community that we interviewed and that regularly used technology to help navigate around said that they think that the technology would be useful to them. They were all incredibly excited about the prospect of moving into the direction of more accessible technology, and finally being more independent when moving around.

• Feedback 2: Summary from partners

We got very good feedback from our partners when they tested the product. We had meetings with them every week, so they could see a nice progression in the UI and also provided valuable feedback (especially about implementing clustering technology and creating a sidebar instead of a "top-bar"). They were also excited to take this further and try and integrate it with their existing technology (especially Soundscape).