Building Robust Programs Defensive design Maintainability Testing Errors

Defensive Design – Planning for misuse • Restrict access – authentication (username, password) • Validation • Verification • Limiting use

Defensive Design - Validation • Length check • Range check • Format check • Presence check • Lookup table / existence check • Check digit 1. Write an algorithm that reads as input a number between 1 and 10 (inclusive) from the user. 2. Write an algorithm that asks the user a question and only allows the user to enter “Yes” or “No”. 3. Write an algorithm that asks the user to enter a code that has 2 letters followed by 3 numbers e. g. LP 123

Defensive Design Validation 1 Do num = input(“Enter number”) Until(isnumeric(num) = TRUE AND num >= 1 AND num <= 10) Do answer = input(“Enter Yes or No”) 2 Until(Ucase(answer) = “YES” OR Ucase(answer) = “NO”) Do 3 user. Input = input(“Enter the code”) Until(is. Char(user. Input[0]) = TRUE AND is. Char(user. Input[1]) = TRUE AND is. Numeric(user. Input[2]) = TRUE AND is. Numeric(usernput[3]) = TRUE)

Maintainability • Help you (or others) understand what the program does, so if it needs editing/improving/fixing in the future, it is easier for whoever does it • Add comments – explain what key functions, algorithms etc. do • Indentation – easier to follow the structure of the program • Appropriate identifiers – relate to what they do

Testing – why? • Test to ensure the algorithm(s) do what they are supposed to do • Test to ensure the program does what it is supposed to do / produces the correct output/outcome • Test to ensure the program cannot be broken by invalid options, selections etc. • Test the program can handle extreme and erroneous data.

Testing - types • Iterative • Carried out during development • Test – Correct/change/add to it – test – correct/change/add to it etc. • Final • Carried out when development is compete • Does the program produce the correct output/outcome? • Can the program be broken?

Types of error • Syntax • The code does not follow the rules/grammar of the language • E. g. no ‘: ’, fi instead of if etc. • Logic • The programmer didn’t program it correctly! • The program does not do what the programmer tried to make it do • Run-time • The program usually works • Occasionally there is an error e. g. stack overflow, division by zero

Test data • Normal • Data that is expected and will be input often • Borderline/extreme • Data that is allowed and expected but at the edge of what is accepted • Erroneous/invalid • Data that is not allowed/should produce an handled error