1. 28/08/2015SJF L31 F21SF Software Engineering Foundations ASSUMPTIONS AND TESTING Monica Farrow EM G30 email : M.Farrow@hw.ac.uk Material available on Vision Dept of Computer Science

2. Overview In this mini-lecture, we think about how much validation you put into a program: What assumptions have been made? What level of validation have you used for input data? If you have coded some checks on input data, you should also have tested that your code performs as you intended. What tests have been passed? For the checks that you haven’t made (or maybe you have, but they are incorrect), we look at what can go wrong 28/08/2015SJF L32

3. 28/08/2015SJF L33 Start by assuming everything is correct”! When we write code for a class, we decide what level of validation should be done Error checking is VERY VERY timeconsuming. It is a good idea to get your basic code working first, assuming that there will be no errors due to incorrect code or incorrect user input. Then modify the code to include error checks as required.

4. 28/08/2015SJF L34 Assumptions – coding errors When we write code for a class, we decide what level of validation should be done Coding errors in the program Do we assume that the parameters of a constructor or method are valid? E.g. a name is not null or an empty string E.g. an integer that should be positive is not negative or 0 Or do we check parameters to make sure they are valid? In this course – don’t check, assume all parameters are ok. In the Advanced Software Engineering course, we look at checking parameters in a bit more detail

5. 28/08/2015SJF L35 Assumptions – user input and data size Errors in user input Ideally, prevent the user from entering anything wrong, using pull-down lists, check boxes etc. Like web page input for countries. Not covered in this course Sometimes the user must enter free text. Errors here might cause your program to crash, or incorrect data to be stored. E.g. text instead of number, incorrect values Unexpectedly large values might cause problems with tabular reports or with GUI layout

6. 28/08/2015SJF L36 Assumptions and checks It’s important that you know What assumptions you are making E.g. assume length < 20 E.g. each row in a csv file has the right number of elements What checks you make for errors, and what happens if you find an error Will program crash? Or behave unexpectedly? Does the user get a nice error message?

7. Example table of limitations This table covers assumptions and user input problems – the program is behaving correctly according to what you have decided to check for. 28/08/2015SJF L37 ProblemEffect Too many qualifications provided in text file Assumes this won’t happen, no checks made. Program will store the extra qualifications and display them, it would affect the appearance of the display A name of 40 characters is entered The name will be accepted but the tabular display will not look good. A user enters a non-numeric value The program does not check for this, and will crash

8. Validation In this course you are asked to do a few validation checks. You could introduce some validation checks for anything that the user enters E.g. length of any name must be in range 2 – 20 characters E.g. an integer is in a given range such as 1 – 5 28/08/2015SJF L38

9. Testing If you do validation checks, you MUST test your program with data that passes and data that fails the test, to ensure that your code is performing as you expect it to. E.g. with a name length in the range 2 – 20, test with 20 It is always a good idea to check values on the boundary, in case you coded ‘<‘ instead of ‘<=‘ Even this doesn’t test ALL possibilities (that’s often impossible), but it gives a good measure of confidence that your code is ok. 28/08/2015SJF L39

10. General testing More generally, you should always test all paths through a program i.e. each route through an activity diagram. Calculations are also important You can then produce a table of tests passed 28/08/2015SJF L310

11. Example table tests passed Tests can be for user input or a method involving calculations or decisions in the code 28/08/2015SJF L311 TestTested Value of ‘age’ is between 18 and 100 Age = 17,18,35,100,101 Initials are returned for a name with and without middle name Tom James Smith => TJS James Robertson => JR Bad choice James Jones – could be taking last initial twice Staff person found using idId = 1234 – 1 st Id = 9877 – last Id = 2343 – middle Id = 1432 – not there

12. Example list of known bugs A list could show coding problems that you know about but have not sorted out. The program behaves wrongly. There shouldn’t be many in this list! E.g. 1. The calculation of minimum salary always returns the last salary. 2. The list of staff is not completely sorted in ID order, some people appear twice in the list and some are omitted. 28/08/2015SJF L312

13. Example list of incompleted work A list could show ways in which your program does not meet the specification. i.e. things you were asked to do that you have not done. E.g. 1. It is not possible to alter the staff level from the GUI 2. The report is not written to the text file 3. The Name class only works if there is always a middle name 28/08/2015SJF L313