This assumes that the call to updatePin is idempotent (calling multiple times with same inputs does not do anything). An update of a I/O pin usually is, but oth

This assumes that the call to updatePin is idempotent (calling multiple times with same inputs does not do anything). An update of a I/O pin usually is, but other hardware (or APIs...) might not be. In this case the realization of the state should still be in a separate function for testability. But it can take both `newState, currentState` as arguments, and then do: if (newState.thingon != currentState.thingon) { nonIdempotentUpdate(newState.thingon); } If the device is latency critical, then the functions should be tested in all its permutations. You can use generative techniques like fuzzing to generate the `state` inputs.