2026-06-03 (3VO): Test Driven Development, Exercise#

Exercise: Logic Extension (Test Driven Development)#

@startuml interface Sensor { + double get_temperature() } class LinuxHWMONSensor {} class DummySensor {} Sensor <|.. LinuxHWMONSensor Sensor <|.. DummySensor interface PWMPin { + void set_duty_cycle(uint64_t) + void set_period(uint64_t) } class LinuxSysfsPWMPin {} PWMPin <|.. LinuxSysfsPWMPin class DummyPWMPin {} PWMPin <|.. DummyPWMPin class Logic { + void loop() } Logic -l-> Sensor Logic -r-> PWMPin @enduml

Requirements To Implement#

The table below is a typical output of a requirements meeting (in reality, feature descriptions that escape such meetings are not so precise). For each entry, create a test suite in the form test-<name>.cpp, and add that to the existing test program (see CMakeLists.txt).

Name

Description

scale-param

The current formula is rather dim:

uint64_t duty_cycle = t/50 * 30*1000*1000;

It implicitly assumes the following:

  • Temperature range (distance between min and max) is 50, on the sensor side

  • Period (in other words: the maximum permissible duty cycle) is 30_000_000 ns, on the PWM side

What we want

  • Parameterize the expected range, by adding min/max parameters to Logic

  • Logic must determine the period automatically, by asking the PWMPin. Note that PWMPin interface currently only has setter methods; for this, we’d need a new interface method, PWMPin::get_period().

overtemperature

There is no safeguard against temperature measurements that exceed the specified range. The effect of such a measurement would be to set the PWM duty cycle to an invalid value (the duty cycle cannot, by definition, be higher than a PWM pin’s period).

Safeguard Logic against overtemperatures. Add a counter where we could ask a Logic instance how many such measurements have occured. This is a first step towards proper reporting of such issues.

undertemperature

Much like overtemperature, only under