Design unit tests for grid navigation
Overview
This question evaluates unit test design, mocking/stubbing of external APIs, deterministic simulation, and correctness of grid-navigation controller logic under edge cases, loops, performance limits, and API error behaviors.
Mouse-Maze Controller: Design a Comprehensive Unit Test Suite
Context (assumptions to make the task self-contained)
Assume we are testing a controller that navigates a grid-based maze to find cheese. The controller drives an abstract Maze API and must return the first cheese it finds according to a deterministic neighbor-order policy. Multiple cheeses may exist; some may be unreachable.
- Grid representation: rectangular grid with walls and open cells.
- Start position: a single cell where the mouse begins.
- Cheese: one or more target cells; reaching any one ends the search successfully.
- Deterministic neighbor exploration order: Up, Right, Down, Left (URDL), unless otherwise specified.
- The Maze API can signal walls/valid moves and may throw errors on move attempts.
- Controller output: either a path (sequence of directions) to a found cheese, or a NotFound/Failure result.
You may minimally adjust the exact API shape but keep behavior semantically equivalent to the above.
Task
Propose a comprehensive set of unit tests for the mouse-maze controller. Include tests for:
- Single-cell maze
- Unreachable cheese
- Narrow corridors and cul-de-sacs
- Loops/cycles
- Large open spaces
- Obstacle directly ahead
- Repeated visits and backtracking correctness
- Multiple cheeses (ensure the first found is returned)
- Performance and stack-depth limits
- API error behavior (e.g., move() throwing)
Also describe how to stub/simulate the Maze API deterministically to support these tests.
Solution
Login required