WEBVTT

1
00:00:00.000 --> 00:00:03.112
Testing the policy on your
computer gives you a controlled way

2
00:00:03.181 --> 00:00:05.851
to ask whether the software
follows its requirements.

3
00:00:06.176 --> 00:00:09.938
In this lesson, we will inspect and
run the basic normal and fault tests.

4
00:00:10.379 --> 00:00:14.199
Start with checkpoint seven. This stage
has native assertions and synthetic

5
00:00:14.257 --> 00:00:18.831
replay, but it does not yet contain
the capstone threshold, hysteresis,

6
00:00:18.901 --> 00:00:22.767
or command parser. The checkpoint
matters when interpreting the output.

7
00:00:23.092 --> 00:00:26.413
Open the README and stage requirements
before the implementation.

8
00:00:26.738 --> 00:00:29.373
The monitor starts in
fault with missing input.

9
00:00:29.652 --> 00:00:33.216
One fresh valid sample remains
in fault with a recovering error.

10
00:00:33.541 --> 00:00:36.978
A second consecutive fresh
valid sample recovers to normal.

11
00:00:37.361 --> 00:00:42.631
Missing, nonfinite, or stale input enters
fault and resets the recovery count.

12
00:00:43.073 --> 00:00:47.043
These are the behaviors we will ask the
tests to establish for controlled cases.

13
00:00:47.426 --> 00:00:51.919
The host harness compiles the actual
shared policy and output source.

14
00:00:52.303 --> 00:00:56.505
The firmware build compiles those shared
files for the selected embedded target.

15
00:00:56.714 --> 00:00:59.373
We are avoiding a separate
test-only implementation

16
00:00:59.431 --> 00:01:03.274
that could behave differently from the
firmware. Shared source is valuable,

17
00:01:03.425 --> 00:01:06.989
but it does not make the host an
electronic simulator or reproduce

18
00:01:07.024 --> 00:01:09.335
the microcontroller's execution timing.

19
00:01:09.718 --> 00:01:12.888
Open the test file and identify
the first monitor instance.

20
00:01:13.131 --> 00:01:15.128
The assertions inspect startup state,

21
00:01:15.279 --> 00:01:17.949
error, and whether a current
temperature is available.

22
00:01:18.275 --> 00:01:20.933
These expectations come
from the requirements.

23
00:01:21.212 --> 00:01:24.660
They should not be chosen simply
because the present implementation

24
00:01:24.835 --> 00:01:28.654
returns those values. A test
that copies the implementation's

25
00:01:28.701 --> 00:01:31.859
assumption can repeat its
error instead of exposing it.

26
00:01:32.300 --> 00:01:36.061
Follow the first two samples.
The first is valid and fresh,

27
00:01:36.236 --> 00:01:39.254
yet the state remains fault
while recovery is incomplete.

28
00:01:39.498 --> 00:01:43.387
The second fresh valid sample
permits normal operation. Notice

29
00:01:43.410 --> 00:01:47.567
the difference between a current numeric
temperature and the overall policy state.

30
00:01:47.950 --> 00:01:50.759
Recovering can have a fresh
value while remaining fault.

31
00:01:51.201 --> 00:01:54.405
That distinction will matter again
when reading the JSON output.

32
00:01:54.916 --> 00:01:59.536
Now inspect the freshness boundary. The
last sample is at timestamp one thousand.

33
00:02:00.233 --> 00:02:01.742
At timestamp four thousand,

34
00:02:01.789 --> 00:02:05.643
its age is exactly three thousand
milliseconds and it remains current.

35
00:02:06.456 --> 00:02:10.844
At four thousand and one, the age exceeds
the limit and the reading becomes stale.

36
00:02:11.169 --> 00:02:13.189
This is a precise equality requirement,

37
00:02:13.398 --> 00:02:16.765
not a general instruction to
expire old data eventually.

38
00:02:17.148 --> 00:02:19.703
The clock values are injected test inputs.

39
00:02:20.028 --> 00:02:23.209
We do not have to wait three real
seconds to check the behavior,

40
00:02:23.360 --> 00:02:26.320
and the timestamps do not
measure physical scheduling.

41
00:02:26.645 --> 00:02:30.256
The arithmetic assumes ordered calls
within the documented interval.

42
00:02:30.535 --> 00:02:35.550
The rollover case exercises the same rule
across the unsigned counter boundary.

43
00:02:35.875 --> 00:02:39.683
It does not establish behavior for
arbitrarily reordered or widely

44
00:02:39.753 --> 00:02:43.723
separated timestamps. Find the
missing and nonfinite cases.

45
00:02:44.048 --> 00:02:48.483
Missing input means the adapter
explicitly failed to supply a value.

46
00:02:48.925 --> 00:02:53.186
NaN and infinity are invalid
numeric inputs. They must enter

47
00:02:53.279 --> 00:02:57.574
fault and prevent the stale or invalid
value from being described as current.

48
00:02:57.749 --> 00:03:02.044
The recovery sequence then checks that
an invalid sample between valid samples

49
00:03:02.427 --> 00:03:05.910
restarts the count instead of
allowing premature recovery.

50
00:03:06.352 --> 00:03:09.672
Run the maintained test wrapper
from the Sensor Monitor root.

51
00:03:09.847 --> 00:03:12.552
The exact PowerShell command
is in the written lesson

52
00:03:12.645 --> 00:03:15.350
and ends in scripts slash test dot cmd.

53
00:03:16.046 --> 00:03:20.237
Inspect the compiler stage, process
result, and reported assertions.

54
00:03:20.841 --> 00:03:25.265
If compilation fails because a tool
is missing, record that setup problem.

55
00:03:25.509 --> 00:03:28.783
It is different from a compiled
program reporting a failed assertion.

56
00:03:29.108 --> 00:03:33.671
A passing test run supports the cases it
actually executed against that source.

57
00:03:34.054 --> 00:03:35.760
Record the checkpoint, command,

58
00:03:35.807 --> 00:03:39.801
compiler information available in
the setup record, and actual result.

59
00:03:40.753 --> 00:03:44.584
Do not treat an assertion count as a
complete quality score. The important

60
00:03:44.619 --> 00:03:48.172
question is whether the cases
distinguish the requirements that matter.

61
00:03:48.555 --> 00:03:51.806
We will deliberately challenge one
of those cases in the next lesson.

62
00:03:52.502 --> 00:03:55.730
Now run the stale-recovery
fixture with the replay wrapper.

63
00:03:55.974 --> 00:04:01.210
This path exercises input interpretation
and output as well as the shared policy.

64
00:04:01.721 --> 00:04:04.542
Read the expected sequence
for checkpoint seven,

65
00:04:04.786 --> 00:04:07.061
not the later alert-capable solution.

66
00:04:07.340 --> 00:04:11.834
The fixture's valid events intentionally
include stale and missing conditions.

67
00:04:12.275 --> 00:04:15.700
A fault state can be the correct
result of a successful replay.

68
00:04:16.083 --> 00:04:19.090
Distinguish three outcomes
as you inspect the terminal.

69
00:04:19.415 --> 00:04:24.094
A valid fixture may produce fault while
the replay process exits successfully.

70
00:04:24.477 --> 00:04:28.146
A malformed fixture can be rejected
with a line-number diagnostic.

71
00:04:28.529 --> 00:04:33.103
A test executable can fail because an
assertion disagrees with the requirement.

72
00:04:33.486 --> 00:04:35.820
Calling all three
situations a failure without

73
00:04:35.878 --> 00:04:39.129
qualification would hide
the next useful action.

74
00:04:39.571 --> 00:04:42.636
Your exercise is to make a
small requirement-to-check map.

75
00:04:42.961 --> 00:04:46.769
Include startup recovery, stale
equality, and nonfinite input.

76
00:04:47.152 --> 00:04:50.530
For each, write the starting
condition, controlled input,

77
00:04:50.681 --> 00:04:53.828
expected outcome, actual
result, and evidence pointer.

78
00:04:54.338 --> 00:04:57.183
Use the requirement to
justify the expectation.

79
00:04:57.624 --> 00:05:02.140
A copied output line is useful only when
its source and procedure are identifiable.

80
00:05:02.523 --> 00:05:04.985
Inspect the timestamped-sample case too.

81
00:05:05.368 --> 00:05:09.408
It distinguishes the time when a value was
acquired from the time it is processed.

82
00:05:09.849 --> 00:05:14.656
A reading supplied now can already be
stale if its acquisition timestamp is old.

83
00:05:14.981 --> 00:05:18.371
This protects against treating
delayed input as a fresh measurement

84
00:05:18.696 --> 00:05:21.970
simply because the adapter delivered
it during the current call.

85
00:05:22.295 --> 00:05:25.662
Pause here to run the available
checks and complete the map.

86
00:05:26.173 --> 00:05:28.309
If a dependency prevents execution,

87
00:05:28.553 --> 00:05:31.932
finish the static inspection and
label the command result open.

88
00:05:32.443 --> 00:05:35.693
Do not fill the result column
with a supplied reference pass.

89
00:05:36.135 --> 00:05:39.478
The reference helps you understand
what should happen, but your own

90
00:05:39.548 --> 00:05:43.461
execution record must say what
actually happened in your environment.

91
00:05:44.064 --> 00:05:47.361
Before finishing, explain
the shared-source diagram.

92
00:05:47.803 --> 00:05:50.844
Host tests and firmware
compilation use the same

93
00:05:50.891 --> 00:05:53.840
policy implementation through
different build paths.

94
00:05:54.444 --> 00:05:58.925
Controlled synthetic input establishes
software behavior for selected cases.

95
00:05:59.250 --> 00:06:02.966
Physical acquisition, electrical
faults, sensor accuracy,

96
00:06:03.117 --> 00:06:07.145
USB behavior, and device timing
remain outside that result.

97
00:06:07.354 --> 00:06:09.665
The limitation is part of the explanation,

98
00:06:09.908 --> 00:06:12.869
not a reason to discard the
useful software evidence.

99
00:06:13.148 --> 00:06:15.853
Keep the preserved good
checkpoint and your receipts.

100
00:06:16.027 --> 00:06:19.719
In the next lesson, we will change
one comparison in a disposable

101
00:06:19.754 --> 00:06:23.156
copy and ask whether the tests
reject the wrong boundary.

102
00:06:23.330 --> 00:06:26.523
That demonstration gives the
passing run more meaning:

103
00:06:26.848 --> 00:06:30.749
it shows a specific defect the suite
can detect while keeping the original

104
00:06:30.830 --> 00:06:34.603
good source available for recovery
and independent comparison.