David Streader Computer Science Victoria University of Wellington Copyright: David Streader, Victoria University of Wellington Debugging COMP T1 13

COMP : 2 © David Streader Overview When the code fails to do what you want it to: 1.Stop pretending 2.Ask your self what is the code actually doing? Errors are often not observed directly. 1.Write test code 1.Setup 2.Execute 3.Observe 2.Write assert statements 3.Stop, execute one step at a time, interrogate sate as you go

COMP : 3 © David Streader Errors and Failures Unexpected behavior is a program error. It is errors that need to be corrected. A program failure occurs when the error is observed. The point at which the failure occurs need not be the same as the point at which the error occurs. The larger the gap the harder to debug. Assertions can narrow the gap between errors and failures.

COMP : 4 © David Streader Test early or suffer badly! As systems grow the cost of change grows. For a system with 1000 components changing one component can easily require the testing of 500 to 1000 components The more quality test code you have the quicker the testing. Develop software using small cycles of code and test Later you will learn Test Driven Development where Junit tests are written before the code. A suite of Junit tests can be run at the touch of button and evaluated at a glance Junit tests will be set up and run using BlueJ.

COMP : 5 © David Streader Test Code Testing can often be broken into three steps: 1.set up the execution 2.execute the method 3.display the results Having run a test the results need to be interpreted

COMP : 6 © David Streader Assertions Java Assert statements verify that some condition is true or throw an Assert exception if they are not true. assert : Use javac –ea or java –enableassertions to compile Java and include assert checks. The default is to omit them. Assert statements serve two main purposes: 1.Document what you believe to be true 2.Aid debugging Production code should not be compiled to include them.

COMP : 7 © David Streader BlueJ compiling assert To Make BlueJ compile assert statements: Very carefully edit line 507 of file Windows - “Program Files\BlueJ\lib\bluej.defs” Mac - bluej.app/Contents/Resources/Java/bluej.defs From bluej.javame.compiler.options=-source 1.4 -target 1.4 To bluej.javame.compiler.options=-source 1.4 -target 1.4 -ea

COMP : 8 © David Streader Where to place assertions Assertion as: 1.Preconditions 2.Postconditions 3.Loop invariants 4.Class invariants Pre and Post conditions often referred to as a contract. Google design by contract

COMP : 9 © David Streader Contracts A contract is an assume guarantee pair Preconditions define what a method assumes. Postconditions define what a method guarantees. The contract for a method is: 1.You give me what I expect then 2.I will guarantee to behave as you want When a precondition fails the error is in the calling code When a post condition fails the error is in the method Knowing where to look for a bug can speed up development. For complex methods it can be easier to read the contract than the code.

COMP : 10 © David Streader Pre Post Conditions To increase sofar the method adds an int parameter The intention behind the method is that: 1.assume that y is not negative. 2.guarantee that sofar is greater than 0. You could not know this by inspecting the code. Strengthen precondition to guarantee postcondition

COMP : 11 © David Streader Exercise Can the isin postcondition be broken? To be sure you need to look at all the methods of the class!

COMP : 12 © David Streader Invariants An invariant is simply a statement that is always true: Loop invariants a statements that are true every time the loop body is executed Object invariants are true before and after any method execution. Pre and post conditions are checked before and after every execution of the method. Constructing useful invariants is far from easy but can be very very useful.

COMP : 13 © David Streader Loop invariant and Postcondition Understand Code Or understand contract

COMP : 14 © David Streader Time is Money The time it takes to write a good program is related to the time it takes to debug your mistakes. Not the time it takes to write the final code. Testing should be undertaken as early as is possible. Only a fool waits till the whole program is written before testing starts How long will it take to run and interpret the tests for 1000 methods? How often will you have to repeat this process? Running and interpreting tests needs to be quick and easy else it will be done far less that is best.

COMP : 15 © David Streader Summary Larger the System the more pay off there is in adopting better test practices Design by contract – Use pre and post conditions Use loop invariants Assertions 1.Capture intention 2.Declare object invariants 3.Can be easier to understand than code 4.Apportion blame 5.Fail faster

COMP : 16 © David Streader Junit Junit has been widely adopted as a framework for unit testing java programs. The tests for the methods of class Foo should appear in a separate class FooTesT. The Junit framework makes use of @Test, … to control when tests are to link test classes into test suites. Test results are recorded using the junit Assert statements APIs provide clear visual feed back as to what tests have been passed and what failed. The point being at the push of a button all the tests can be performed and if all tests are passed a light turns green.

COMP : 17 © David Streader BlueJ and Junit Check Preferences>Interface>Show unit testing tools BlueJ allows objects to be built and methods to be executed via interaction with an easy to understand GUI. Hence once helper methods have been written you can test a method by interacting with the GUI to set up the data, run the method under test and inspect the results. Having indicted that you wish to build a test class BlueJ allows you to build a test method and then record your interaction with the GUI as method calls in the Junit test class. The output from BlueJ is a Junit test class that can be edited just like any other Java class file.