Weather Station

Level: Advanced 60–90 min

Concepts: StateAlgorithms

Solutions: C# | TypeScript | Python

Implement a weather station system that processes weather data, calculates statistics, and predicts trends. The system should handle various weather parameters and provide meaningful insights.

Requirements

  1. Process weather data
    • Temperature (current, min, max, average)
    • Humidity levels
    • Barometric pressure
    • Wind speed and direction
    • Precipitation amounts
  2. Calculate statistics
    • Daily, weekly, and monthly averages
    • Trend analysis
    • Extreme weather conditions
    • Weather patterns
  3. Generate reports
    • Current conditions
    • Historical data analysis
    • Weather forecasts
    • Alert conditions

Hint

Start by implementing the basic data collection and storage, then add the statistical calculations. Consider using a time-series database or similar structure for efficient data storage and retrieval. Think about:

  • Data validation and error handling
  • Efficient data storage and retrieval
  • Statistical accuracy and precision
  • Real-time processing requirements

Bonus

  • Implement weather prediction algorithms
  • Add support for multiple weather stations
  • Create a visualization system for weather data
  • Implement weather alerts and notifications
  • Add support for different units of measurement

Reference Walkthrough

Full C#, TypeScript, and Python implementations live at tddbuddy-reference-katas/weather-station with the same twenty-four scenarios across all three languages, fluent StationBuilder and ReadingBuilder, a Clock collaborator so tests don’t depend on real time, and configurable alert thresholds.

This kata ships in middle gear — a single commit per language with the full domain design. The Station aggregate records validated weather readings, computes min/max/average statistics across temperature, humidity, and wind speed, and evaluates configurable alert thresholds. See the repo’s Gears section for why that’s a deliberate teaching choice.

Related reading

  • Katas Are Rehearsal, Not Performance
    You don't practice TDD on production code. You practice on katas and bring the muscle memory to production. The gap between knowing TDD and doing TDD is reps.
  • The Contract Test Is the Only Witness the Agent Cannot Author
    A test the agent wrote against code the same agent wrote shares the agent's blind spot: a misunderstanding in the implementation becomes a matching misunderstanding in the test, the bar goes green, and the bug ships certified. Consumer-driven contract tests are the only category where a second team publishes the assertion the first team has to satisfy. That separation of authorship is exactly what tamper-resistant test design demanded, applied at the integration seam.
  • Test Deletion Is a Privileged Operation
    The cheapest way for an agent to make a failing test pass is to delete it. That is logical for the agent and catastrophic for the codebase. Tests are append-only by default. Deletion needs a human author, a separate commit, and a separate review.