WEBVTT

1
00:00:00.000 --> 00:00:01.242
A passing test becomes more

2
00:00:01.265 --> 00:00:04.063
informative when you know a
meaningful defect it can detect.

3
00:00:04.667 --> 00:00:08.707
In this lesson, we will deliberately
change one freshness comparison, show

4
00:00:08.753 --> 00:00:13.003
that the wrong version still compiles, and
inspect the resulting behavioral failure.

5
00:00:13.514 --> 00:00:16.195
Use a new checkpoint-seven exercise copy.

6
00:00:16.521 --> 00:00:20.050
Preserve the good source and its
result before introducing the fault.

7
00:00:21.002 --> 00:00:22.535
Read the requirement first.

8
00:00:22.813 --> 00:00:26.726
A sample remains current at an age of
exactly three thousand milliseconds.

9
00:00:27.051 --> 00:00:30.952
It becomes stale only when its age is
greater than that limit. This distinction

10
00:00:30.998 --> 00:00:34.586
defines the correct comparison.
The test's expected result must come

11
00:00:34.609 --> 00:00:38.730
from that contract, not from whichever
operator happens to be in the code today.

12
00:00:39.334 --> 00:00:43.142
Open the shared policy implementation
and locate Monitor poll.

13
00:00:43.653 --> 00:00:47.136
Inspect the whole condition before
editing. It checks that a value

14
00:00:47.171 --> 00:00:50.956
is current and compares unsigned
elapsed time with the stale limit.

15
00:00:51.281 --> 00:00:54.264
The intentional mutation changes
the greater-than operator

16
00:00:54.589 --> 00:00:57.701
to greater-than-or-equal.
Nothing else should change.

17
00:00:58.084 --> 00:01:02.647
We want to isolate one semantic error that
a reader can explain from a small diff.

18
00:01:02.972 --> 00:01:06.397
This mutation is different from the
supplied fault-stale checkpoint.

19
00:01:06.675 --> 00:01:09.368
That checkpoint disables
expiration entirely.

20
00:01:09.693 --> 00:01:14.314
Here, expiration still happens, but it
happens one boundary step too early.

21
00:01:14.593 --> 00:01:18.505
Keeping the two faults distinct prevents
us from attributing the wrong cause

22
00:01:18.529 --> 00:01:21.826
to the observed output. Both
can teach useful lessons,

23
00:01:21.977 --> 00:01:24.519
but they answer different
questions about the tests.

24
00:01:24.961 --> 00:01:29.187
First run the unmodified basic tests
and preserve the actual result.

25
00:01:29.465 --> 00:01:31.125
If the baseline does not pass,

26
00:01:31.334 --> 00:01:34.562
investigate that condition before
adding a deliberate defect.

27
00:01:34.945 --> 00:01:38.893
Otherwise, you cannot separate an
existing problem from the mutation

28
00:01:38.951 --> 00:01:42.991
you are about to introduce. Record
the source identity and command

29
00:01:43.270 --> 00:01:47.020
so the starting evidence remains
connected to the right exercise copy.

30
00:01:47.461 --> 00:01:50.863
Now make the one-character
change in the disposable source.

31
00:01:51.188 --> 00:01:55.576
Review the diff immediately. Confirm
that the changed comparison is inside

32
00:01:55.599 --> 00:01:59.895
the polling expiration guard rather
than in another input-validation path.

33
00:02:00.174 --> 00:02:04.063
An accidental additional edit would
make the experiment harder to interpret.

34
00:02:04.342 --> 00:02:08.498
Preserve the good copy instead of relying
on memory to reconstruct it later.

35
00:02:08.939 --> 00:02:13.142
Run the same maintained test wrapper.
The wrong version should compile and then

36
00:02:13.188 --> 00:02:17.240
be rejected by the relevant behavioral
assertions. If you accidentally create

37
00:02:17.263 --> 00:02:21.385
a syntax error, fix that typing mistake
before interpreting the experiment.

38
00:02:22.082 --> 00:02:26.912
A compiler error proves that the compiler
rejected invalid source; it does not

39
00:02:26.958 --> 00:02:31.265
prove that the freshness assertions
distinguish the wrong equality behavior.

40
00:02:31.962 --> 00:02:35.039
Read the assertion failure and
connect it to the requirement.

41
00:02:35.643 --> 00:02:38.255
The ordinary case uses
a sample at timestamp

42
00:02:38.336 --> 00:02:40.542
one thousand and checks
it at four thousand.

43
00:02:40.867 --> 00:02:44.315
Its age is exactly three thousand,
so it must remain current.

44
00:02:44.698 --> 00:02:46.951
The mutated comparison marks it stale.

45
00:02:47.229 --> 00:02:49.505
That is the concrete
trigger and consequence,

46
00:02:49.714 --> 00:02:53.209
stated independently of the test
framework's wording or line number.

47
00:02:53.650 --> 00:02:58.027
The rollover equality case can expose the
same mistake across the unsigned clock

48
00:02:58.085 --> 00:03:02.369
boundary. It checks the contract under
another relevant timestamp arrangement.

49
00:03:02.973 --> 00:03:06.897
Do not treat multiple failed assertions
as unrelated bugs automatically.

50
00:03:07.594 --> 00:03:10.008
A single wrong comparison
can cause several

51
00:03:10.066 --> 00:03:12.609
observations to disagree
with the same requirement.

52
00:03:13.213 --> 00:03:16.591
Explain their shared cause before
broadening the investigation.

53
00:03:16.974 --> 00:03:21.410
Do not change the expected values to make
the wrong source pass. That would erase

54
00:03:21.445 --> 00:03:25.485
the independent requirement and teach
the tests to accept the defect. Tests

55
00:03:25.520 --> 00:03:29.653
can be wrong, but correcting them requires
an argument from the specification.

56
00:03:30.094 --> 00:03:33.821
Here the equality condition is explicit,
so the implementation is the thing

57
00:03:33.867 --> 00:03:36.026
that must return to the
documented behavior.

58
00:03:36.468 --> 00:03:39.312
Restore exactly the original
greater-than comparison.

59
00:03:39.695 --> 00:03:42.377
Inspect the diff again and
run the same test command.

60
00:03:42.702 --> 00:03:44.954
The original good version
should still pass.

61
00:03:45.280 --> 00:03:47.938
Preserve the bad result as
well as the restored result.

62
00:03:48.321 --> 00:03:51.793
A final passing screenshot alone
would hide the useful demonstration

63
00:03:51.839 --> 00:03:54.254
that the suite rejected
the specific defect.

64
00:03:54.637 --> 00:03:58.306
Because the exercise changed
shared firmware source, reproduce

65
00:03:58.341 --> 00:04:02.462
the firmware cross-build after restoration
using the maintained build wrapper.

66
00:04:02.846 --> 00:04:06.445
Record its actual outcome separately
from the host assertion result.

67
00:04:06.770 --> 00:04:10.798
The cross-build checks the restored
source against the selected target inputs.

68
00:04:11.181 --> 00:04:15.234
It does not establish an upload, a
physical reading, or real device timing.

69
00:04:15.675 --> 00:04:19.344
Your evidence record should contain
the baseline result, the seeded diff,

70
00:04:19.587 --> 00:04:23.349
successful compilation of the bad
version, the relevant assertion failure,

71
00:04:23.465 --> 00:04:27.865
the restoration, and the passing rerun.
Explain which condition failed and why.

72
00:04:28.191 --> 00:04:31.546
You do not need to claim that every
possible defect would be detected.

73
00:04:31.871 --> 00:04:34.564
The evidence supports this
particular test capability.

74
00:04:35.006 --> 00:04:38.628
Preserve standard output and diagnostic
output when recording the run.

75
00:04:38.953 --> 00:04:41.519
The process exit communicates
success or failure,

76
00:04:41.693 --> 00:04:45.710
while the assertion message explains the
disagreement. A screenshot that shows

77
00:04:45.803 --> 00:04:50.087
only a command prompt after execution
can lose both pieces of information.

78
00:04:50.691 --> 00:04:53.535
Keep the receipt readable enough
to establish which source ran

79
00:04:53.651 --> 00:04:55.579
and why the behavioral check rejected it.

80
00:04:56.275 --> 00:04:58.179
Pause now to complete the exercise.

81
00:04:58.620 --> 00:05:02.510
If the result differs from the expected
sequence, preserve it and inspect

82
00:05:02.533 --> 00:05:05.935
the active checkpoint, exact
changed line, and command.

83
00:05:06.631 --> 00:05:10.568
A different source version or accidentally
modified assertion can explain

84
00:05:10.614 --> 00:05:14.515
the discrepancy. Do not replace
the actual output with the course's

85
00:05:14.573 --> 00:05:17.940
expected result just to make the
demonstration appear complete.

86
00:05:18.381 --> 00:05:22.061
When reviewing your submission, ask
whether a person can follow the chain

87
00:05:22.131 --> 00:05:25.939
from requirement to mutation to
observed failure to recovery.

88
00:05:26.450 --> 00:05:31.198
A tiny code change can have a precise
behavioral consequence. The test is useful

89
00:05:31.256 --> 00:05:35.180
because it makes that consequence visible,
not because it produces a large amount

90
00:05:35.215 --> 00:05:37.932
of terminal output or an
impressive number of assertions.

91
00:05:38.536 --> 00:05:41.647
Keep the meaningful rejection
case with your verification notes.

92
00:05:42.030 --> 00:05:45.548
After a relevant refactor, it can
help confirm that the suite still

93
00:05:45.606 --> 00:05:48.880
distinguishes premature staleness
from the required boundary.

94
00:05:49.321 --> 00:05:53.420
The general habit transfers beyond
this project: preserve a good baseline,

95
00:05:53.664 --> 00:05:57.506
seed a realistic defect in isolation,
prove behavioral rejection,

96
00:05:57.576 --> 00:06:01.256
and restore the original result without
concealing any part of the evidence.