1. Week 10
Tracing, Testing,
Debugging, API
Design

2. © 2004 Pearson Addison-Wesley. All rights reserved 5-2
Copyright Warning
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
WARNING
This material has been copied and communicated to you by or
on behalf of Bond University pursuant to Part VB of the
Copyright Act 1968 (the Act).
The material in this communication may be subject to copyright
under the Act. Any further copying or communication of this
material by you may be the subject of copyright protection
under the Act.

3. © 2004 Pearson Addison-Wesley. All rights reserved 5-3
Robust Programs
• We have seen that our programs can be fragile
• Programs also need to be read by humans so they
can be fixed and extended
• This week we are looking at techniques to make
our programs more robust, and more easily
understood by other programmers
• We will be looking at:
– Tracing, debugging and unit testing
– Good API design

4. © 2004 Pearson Addison-Wesley. All rights reserved 5-4
Why Do Programs Have Bugs?
• Programs have bugs for several reasons:
– Computers DWIS not DWIM
– Inputs can have any or all possible values
– We don't understand the language subtleties
– Our understanding of the interfaces between the
modules in our program, and with external
modules, is wrong
• Let's look at some ways of combatting these
problems

5. © 2004 Pearson Addison-Wesley. All rights reserved 5-5
Tracing Programs
• We don't think like a computer, but to write good
programs we need to.
• Tracing a program means to step through some
code, by hand, and track all the variable values
and decisions made, to ensure that the code is
doing exactly what it should be doing.
• If we don't understand our own code, we can fall
into the trap of shotgun debugging: making
random changes in the hope that any problems
will disappear.

6. © 2004 Pearson Addison-Wesley. All rights reserved 5-6
Tracing Programs
• Trace the following code when it is given the input “Paul McCartney”
public static String changeString(String s)
{
String x = "";
for (int i=0; i < s.length(); i += 2)
{
if (s.charAt(i) < 'M')
x = x + ".";
x = x + Character.toUpperCase( s.charAt(i) );
}
return(x);
}

7. © 2004 Pearson Addison-Wesley. All rights reserved 5-7
Tracing Programs
• Why tracing?
• It forces us to read each line of code, think about
what it is doing, why it is there, and what side
effects each line has
• It also makes us do things slowly
• We will focus more deeply on the code
• Sometimes, we also reflect on questions such as
the quality of the code, could it be done better etc.

8. © 2004 Pearson Addison-Wesley. All rights reserved 5-8
Debugging Programs
• Debugging is like tracing but the computer looks
after the display of variables and the stepping
through the code
• Don't start at main(). Try to identify where the bug
is, and debug from just before the bug
• Learn how to:
– Set up breakpoints (stop signs)
– Step over lines of code
– Visualise the variables' values
– Step over, and into, methods

9. © 2004 Pearson Addison-Wesley. All rights reserved 5-9
Debugging Programs
• Find the bug(s) in this method:
// Return the position of the first ch in the String,
// or return -1 if ch is not in the String.
public static int findLetter(String str, char ch)
{
for (int i=0; i <= str.length(); i++)
if (str.charAt(i) == ch)
return(i);
return(-1);
}

10. © 2004 Pearson Addison-Wesley. All rights reserved 5-10
Methods and Inputs
• Every method has a declaration, which is its
contract: if you give me this input, I promise to
return this value
• Inputs, regardless of where they come from, are
problematic
• If an input is of type X, any valid X value may come
in as input:
 int: zero, negative values, large values
 floats: 0.0, INFINITY, very small values
 Strings: empty String, null
 char: non-printable chars, non-English chars

11. © 2004 Pearson Addison-Wesley. All rights reserved 5-11
Unit Testing
• All large programs have bugs: usual estimate is 1
bug per 100 lines of code
• Most bugs are logic bugs: the programmer thinks
it works, but the code does something different
• It's nearly impossible to tell if a program is 100%
bug-free
• Implication: programs should be tested thorougly
to give assurance there are no bugs
• Unit testing: test a method with a large set of
inputs, to ensure that it produces the correct
output
• The test set is designed to stress the method as
much as possible

12. © 2004 Pearson Addison-Wesley. All rights reserved 5-12
Unit Testing
• You should design the method interface first
• THEN, construct a suitable test set for it
 Include good and bad inputs
• ONLY THEN, write the actual method code
• Once you think you have written the method, you
can then test the method with the unit tests
• “Coding isn't complete until all the unit tests pass”
• ALWAYS generate the tests by hand. Don't use a
program to generate the test set. Why not?
• Bluej provides a framework to construct unit tests.
• You will see it in the labs, and you will be
assessed on unit testing

13. © 2004 Pearson Addison-Wesley. All rights reserved 5-13
Unit Test Example
• Design the declaration of a method isATriangle()
• Given 3 side lengths, return true if they represent a
triangle, false otherwise
• Create a set of unit tests (inputs, output) that you
can use to test the method.
• In BlueJ, write the method to always return false
 So we can write the unit tests, which will fail
• Now go and write the code.
• Once all the unit tests pass, you now have
confidence that the code works

14. © 2004 Pearson Addison-Wesley. All rights reserved 5-14
API Design
• A method provides an interface: name, inputs,
output
• A Java class provides a set of interfaces, known
as an API: application program interface
• APIs can be designed well, or extremely bad
• Here are some tips on good API design
• Names mean everything. Choose wisely
• Methods perform actions. Use action names, e.g.
getUserName() not UserName()
• Make it obvious if a method is a getter or a setter
• Boolean methods: use “Is”, e.g. isEnrolled()

15. © 2004 Pearson Addison-Wesley. All rights reserved 5-15
API Design
• Method arguments: keep consistent order across
the methods in the API, e.g. (hroom, wroom) in
Assignment 2.
• Make it hard for user to get wrong, easy to get
right
 e.g if method takes 2 ints and a char, make it
method(int, char, int), so hard to get the ints the
wrong way around
• Encapsulation: private data, public methods,
public constants, private helper methods

16. © 2004 Pearson Addison-Wesley. All rights reserved 5-16
API Design
• A method provides an interface: name, inputs,
output
• Clear and concise documentation at the top of
each method tells the user what it does, and how it
deals with input errors.
• Design a clear description of the isATriangle()
method