You inherit a Python data-science pipeline that loads a file, builds features, trains a model, and writes predictions. Describe the unit tests you would add and the command-line interface you would provide so the workflow can run reproducibly in local development and automation. ### Constraints & Assumptions - Tests must use small synthetic fixtures rather than production data. - The pipeline should fail clearly on invalid input and should be runnable without editing source code. - The goal is to test the team's logic, not third-party library internals. ### Clarifying Questions to Ask - Which stages are pure functions, and which read files or external resources? - What schema and invariants must input data satisfy? - Which artifacts should a run produce, and how should they be versioned? - Does the command need separate train, evaluate, and predict modes? ### What a Strong Answer Covers - Unit tests for transformations, joins, leakage boundaries, edge cases, and deterministic metric calculations. - Integration tests for a tiny end-to-end run, with external I/O isolated or mocked appropriately. - Assertions for schema, uniqueness, row counts, ranges, missing values, and feature/target alignment. - A command-line design with explicit inputs, outputs, configuration, seeds, useful exit codes, and safe defaults. - Reproducible environments, structured logging, artifact metadata, and automation in continuous integration. ### Follow-up Questions 1. How would you test that a join does not duplicate observations? 2. What should happen when a required column is missing? 3. Which tests would detect training-serving preprocessing drift? 4. When is mocking harmful in a data pipeline test?