Testing and debuggingPrint statementsDebugging output methods, IDebugging output methods, IIProgram to capture outputtoString()Review: Overriding methodsThe EndJan 13, 2019Testing and debuggingA short interludePrint statementsAn old-fashioned, but still very useful, debugging technique is putting in print statementsHowever, it’s a nuisance to remove them again (then add them again, then remove them again...)Here’s a helpful technique:boolean debugging = true;debug("Some debugging message...");private void debug(Object obj) { if (debugging) System.out.println(obj);}Debugging output methods, IJUnit testing should not produce any output that you have to look at--it should be fully automaticFirst, consider whether you can separate the output method into one method that computes the output, and another method that actually prints itThen you can test the former methodSince a String can contain newlines, you are not restricted to single-line outputSeparation of concerns is good practice in any caseDebugging output methods, IIYou can also change (maybe temporarily) where the output goesPrintStream usualSystemOut = System.out; // save old streamSystem.setOut(someOtherPrintStream); // use new streamSystem.setOut(usualPrintStream); // change it backYou can write to a file, then test whether the file has the right contentsHere's a more sophisticated approach:Use a ByteArrayOutputStream to capture the output in a byte arrayUse the ByteArray's toString() method to examine the outputComplete sample code is on the next slideProgram to capture output public static void main(String[] args) { PrintStream originalOut = System.out; OutputStream os = new ByteArrayOutputStream(); PrintStream ps = new PrintStream(os); System.setOut(ps); System.out.print("Hello, output!"); System.setOut(originalOut); System.out.println("I got: [" + os.toString() + "]"); }I got: [Hello, output!]toString()In general, you want to avoid unnecessary methods in your classes, but......It’s usually a good idea to override toString()Having a toString() method often simplifies debugging, because you can see what your objects really areDon’t use your toString() methods to compare objects in your JUnit tests, unless you are very sure you will never change the string representation of your objectsFor JUnit testing (especially with assertEquals), you should have a good version of public boolean equals(Object o)The default equals method tests identity, not equality, and this is probably not what you wantReview: Overriding methodsTo override a method is to write a method that has the exact same signature as an inherited methodThe names of parameters are not part of the signature, so they can be different if you really wantYou cannot override a method with a less public method (but it can be more public if you want)You cannot throw any checked exceptions that the inherited method doesn’t throwIn Java 5, you should precede your method with @OverrideExamples:public String toString() { ... }public boolean equals(Object o) { ... } // Notice type of parameter!The EndEclipse Hints ● You can put a “task” in any comment: ● TODO -- code to be written ● FIXME -- error to be fixed ● XXX -- need to think more about this To show tasks, choose ● Window Show view Other...
View Full Document
Unlocking...