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

.. topic:: Material

   From :doc:`/trainings/material/soup/misc/unittest/index`:
   
   * :doc:`/trainings/material/soup/misc/unittest/unittest_gtest_basics/topic`
   * :doc:`/trainings/material/soup/misc/unittest/unittest_gtest_cmake/topic`
   * :doc:`/trainings/material/soup/misc/unittest/unittest_gtest_fixture/topic`

Exercise: ``Logic`` Extension (Test Driven Development)
-------------------------------------------------------

.. topic:: Temperature Display Evolution

   * :doc:`2026-05-11`
   * :doc:`2026-05-16`
   * :doc:`2026-05-22`

.. plantuml::

   @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``).

.. list-table::
   :align: left
   :header-rows: 1

   * * Name
     * Description
   * * ``scale-param``
     * The current formula is rather dim: 

       .. code-block:: c

	  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``