Designing and testing programs onscreen

Hello students, welcome to Kwickprep. Your program runs without an error message. Does that prove it is correct? Not at all. Today we will learn how to design a program and test it properly on screen, in a code editor.

Some exams test programming onscreen, on a computer, instead of on paper. You write real Python code in a code editor and run it. The editor is usually an IDE, short for integrated development environment, which helps you write, run and debug code. Because you can run code, you should test as you go, not only at the end. Save your work often, and keep any file names you are given.

Good programs are designed before they are coded. First, understand exactly what the requirements ask. Second, decompose the problem into smaller parts. Third, decide the inputs, processes and outputs of each part. Fourth, write the algorithm as a flowchart or in pseudocode, so the logic is clear before you type.

Here is a design for a cinema ticket price. First, the program inputs the age. The diamond asks, is age less than twelve? If yes, the price is fifty rupees. If no, the flow goes down and the price is one hundred rupees. Then the program outputs the price and stops.

The same design can be written in pseudocode. Receive age from keyboard is the input. If age is less than twelve, set price to fifty, else set price to one hundred. Send price to display is the output.

Now we turn the design into Python. We put the logic in a function called ticket, so it is easy to test with many ages. If age is less than twelve, it returns fifty. Otherwise it returns one hundred. Age eight gives fifty and age thirty gives one hundred, which matches the design.

Testing means running the program with chosen data to find errors. Normal data is typical, valid data the program should accept, like age thirty. Boundary data sits at the edge of a range, like eleven and twelve, where the rule changes. Erroneous data is invalid and should be rejected, like minus five or the word ten.

A test plan lists each test before you run it. Age thirty should give one hundred, and it does. Age eleven should give fifty, and it does. Age twelve should give one hundred, and it does. Age minus five should be rejected, but the program gives fifty. That failed test shows a missing validation check.

Pause and predict. The rule says anyone under twelve pays fifty rupees. A student writes if age is less than or equal to twelve. Which test catches this mistake? Only the boundary test with age twelve, which wrongly gives fifty. Normal data like thirty would never find it.

Now we refine the program to fix the failed test. Before anything else, we check whether the age is less than zero or greater than one hundred twenty. If so, the function returns Invalid age. Running ticket of minus five now prints Invalid age. After every fix, run all the earlier tests again, to be sure nothing else broke.

There are two times to test. Iterative testing happens while you code, testing each small part as soon as you write it. Final testing happens when the whole program is complete, checking that all parts work together and meet every requirement.

When a test fails, you debug, which means finding and removing the error. First, read the error message carefully, including its line number. Next, add print statements to see how values change. Many IDEs also have a debugger that runs one line at a time. Always change one thing at a time, then run again.

Let us revise what we learned today. Design first, by decomposing the problem and drawing a flowchart or writing pseudocode. Then code the design, often as small functions. Test with normal, boundary and erroneous data. Record the expected and actual result for every test in a test plan. When a test fails, fix it and retest everything. A program that runs is not the same as a program that is correct.