Chapter 9 — Programming II
Lesson map
Lesson 09 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Modules"]
N2["9.2 Unit tests for rules"]
N3["9.3 Version control"]
N4["9.4 Code review for data rules"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 Modules"]
N2["9.2 Unit tests for rules"]
N3["9.3 Version control"]
N4["9.4 Code review for data rules"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]
[Learning outcomes]
|
v
[9.1 Modules]
|
v
[9.2 Unit tests for rules]
|
v
[9.3 Version control]
|
v
[9.4 Code review for data rules]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes
You will (1) structure data processing code into tested modules; (2) write unit tests for quality rules; (3) use version control for rule changes.
9.1 Modules
Kofi reorganises his scripts into modules: one for reading files, one for validation rules, one for reporting. Each module has a clear interface. The validation module exposes a list of rules, each with a name, a description and a function. This structure lets data owners read the rule descriptions without reading code, and lets engineers add or change rules without touching the reader or reporter. He notes that clear separation reduces the chance of accidental changes affecting unrelated behaviour. Rule descriptions form a catalogue.
9.2 Unit tests for rules
For each rule, Kofi writes unit tests with synthetic cases that should pass and cases that should fail. The test for readings not below the previous value includes a meter replacement, where readings legitimately reset to zero. The first version of the rule wrongly rejects replacements, and the test reveals it. He adds a meter replacement flag to the rule. Prof. Varga emphasises that tests document the intended behaviour of rules as clearly as any written policy. The flag comes from the work order system.
9.3 Version control
All rule changes are made through version control with a message explaining why. When the meter replacement exception is added, the commit message links to the decision record. Kofi can show exactly when a rule changed and compare quality reports before and after. He explains that version history is evidence for auditors and for data owners who notice a sudden change in reject rates and want to know whether data or rules changed. Every change to the rule list is reviewed by a second engineer before it is merged into the main branch.
9.4 Code review for data rules
Kofi asks a metering engineer to review the rules, not just a programmer. The engineer points out that some older meters report readings only daily, so an hourly completeness rule would fail them unfairly. Kofi adds meter type as a parameter. He learns that domain experts catch errors that code reviewers miss, and that governance rules need both technical correctness and business correctness to be useful rather than just enforceable. Daily meters are now judged against a daily completeness rule, and their reject rate falls to the same level as hourly meters.
Worked example
Kofi structures code into modules with named rules, writes tests that catch a meter replacement error, links rule changes to decisions in version control and gains domain review that adds meter type.
Synthetic case. Code and data are synthetic.
Errors and limits
Tests cover only cases someone thought of; add cases from real incidents.
Exercises
- EX025 — Rule structure. What does each rule expose? Rubric: 3 = name, description and function;; 2 = all;; 1 = one;; 0 = none.
- EX026 — Test catch. What did the unit test reveal? Rubric: 3 = rule wrongly rejected meter replacements;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX027 — Domain review. What did the metering engineer point out? Rubric: 3 = older meters report only daily;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 09 (chapter 09 of 50)
← Chapter 08 · Course chapter index · Chapter 10 →
Continue to the next authored lesson.