Chapter 3 — Programming foundations
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Safe scripts"]
N2["3.2 Logging"]
N3["3.3 Input validation"]
N4["3.4 Test data generation"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Safe scripts"]
N2["3.2 Logging"]
N3["3.3 Input validation"]
N4["3.4 Test data generation"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Safe scripts]
|
v
[3.2 Logging]
|
v
[3.3 Input validation]
|
v
[3.4 Test data generation]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) write scripts that handle member data safely; (2) avoid printing or logging personal data; (3) use test data.
3.1 Safe scripts
Aisha writes Python scripts to count class attendance. Mr. Reilly requires synthetic member data for all exercises. Her script reads a file of bookings, counts attendance per class and prints totals. She avoids printing member names, which are not needed for totals. She learns that scripts are often copied and reused, so habits formed in simple scripts spread into production systems. Her script therefore groups bookings by class code and date, and the only output is a table such as Spin Tuesday 18:00 with twenty-two attendees.
3.2 Logging
Aisha adds logging to her script to help debugging. Her first version logs each booking with the member name. She changes it to log only booking references and counts. She explains that logs are often kept longer and accessed by more people than the data they describe, so personal data in logs create unnecessary exposure. In her script, a log line now reads booking B-10422 counted for class SPN-18, which still lets her trace an error back to the source file without revealing who attended the class.
3.3 Input validation
Aisha's script reads files exported from the booking system. She adds checks that the file has only expected columns and stops if it includes unexpected ones such as health notes. She explains that validation supports data minimisation, since a script should not process data it does not need, and that stopping loudly is better than silently processing sensitive information. Her check compares the header row with an allowed list of five columns and exits with a message naming any extra column, such as medical_notes.
3.4 Test data generation
Aisha writes a generator for synthetic members with names, ages, membership types and bookings. She includes edge cases, such as members with long names or no bookings. She shares the generator with classmates. Mr. Reilly notes that good test data make development safer and faster, and that using real member data for testing is a common cause of breaches. Her generator uses a fixed random seed, so classmates who run it get identical members and can compare their results line by line.
Worked example
Aisha writes an attendance script that prints totals without names, logs references only, rejects unexpected columns and generates synthetic members with edge cases.
Synthetic case. Scripts and members are synthetic.
Errors and limits
Synthetic data may miss real-world quirks; add them deliberately.
Exercises
- EX007 — No names in totals. Why does Aisha's script not print names? Rubric: 3 = totals do not need them;; 2 = mentions minimisation;; 1 = prints;; 0 = none.
- EX008 — Log content. What does Aisha log instead of names? Rubric: 3 = booking references and counts;; 2 = mentions references;; 1 = names;; 0 = none.
- EX009 — Real test data. Why avoid real member data in testing? Rubric: 3 = it is a common cause of breaches;; 2 = mentions risk;; 1 = fine;; 0 = none.
Continue studying — lesson 03 (chapter 03 of 30)
← Chapter 02 · Course chapter index · Chapter 04 →
Continue to the next authored lesson.