1 / 20

Chapter 15: Discovering problems

Chapter 15: Discovering problems. There are some tools that we can use to discover problems Junit: for unit testing Ant as a make utility CVS as a version control Logging Debugging Profiling. JUnit. A framework for white-box unit testing

airlia
Download Presentation

Chapter 15: Discovering problems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 15: Discovering problems • There are some tools that we can use to discover problems • Junit: for unit testing • Ant as a make utility • CVS as a version control • Logging • Debugging • Profiling

  2. JUnit • A framework for white-box unit testing • There is a TestCase class in the framework that we extend to implement our tests • Each those subclass can contain a number of tests which is implemented as public methods beginning with the word “test” • Also we can define a setUp() method which is called before each test • And a tearDown() which is called after each test • Junit uses reflection to find tests and execute them

  3. A sample Junit test case import junit.framework.*; // So we can see the list objects being created, // and keep track of when they are cleaned up: class CountedList extends ArrayList { private static int counter = 0; private int id = counter++; public CountedList() { System.out.println("CountedList #" + id); } public int getId() { return id; } } public class JUnitDemo extends TestCase { private static com.bruceeckel.simpletest.Test monitor = new com.bruceeckel.simpletest.Test(); private CountedList list = new CountedList(); // You can use the constructor instead of setUp(): public JUnitDemo(String name) { super(name); for(int i = 0; i < 3; i++) list.add("" + i); }

  4. A sample Junit test case (cont.) // Thus, setUp() is optional, but is run right // before the test: protected void setUp() { System.out.println("Set up for " + list.getId()); } // tearDown() is also optional, and is called after // each test. setUp() and tearDown() can be either // protected or public: public void tearDown() { System.out.println("Tearing down " + list.getId()); } // All tests have method names beginning with "test": public void testInsert() { System.out.println("Running testInsert()"); assertEquals(list.size(), 3); list.add(1, "Insert"); assertEquals(list.size(), 4); assertEquals(list.get(1), "Insert"); } public void testReplace() { System.out.println("Running testReplace()"); assertEquals(list.size(), 3); list.set(1, "Replace"); assertEquals(list.size(), 3); assertEquals(list.get(1), "Replace"); }

  5. A sample Junit test case (cont.) // A "helper" method to reduce code duplication. As long private void compare(ArrayList lst, String[] strs) { Object[] array = lst.toArray(); assertTrue("Arrays not the same length", array.length == strs.length); for(int i = 0; i < array.length; i++) assertEquals(strs[i], (String)array[i]); } public void testOrder() { System.out.println("Running testOrder()"); compare(list, new String[] { "0", "1", "2" }); } public void testRemove() { System.out.println("Running testRemove()"); assertEquals(list.size(), 3); list.remove(1); assertEquals(list.size(), 2); compare(list, new String[] { "0", "2" }); } public void testAddAll() { System.out.println("Running testAddAll()"); list.addAll(Arrays.asList(new Object[] { "An", "African", "Swallow"})); assertEquals(list.size(), 6); compare(list, new String[] { "0", "1", "2", "An", "African", "Swallow" }); }

  6. A sample Junit test case (cont.) public static void main(String[] args) { junit.textui.TestRunner.run(JUnitDemo.class); monitor.expect(new String[] { "CountedList #0", "CountedList #1", "CountedList #2", "CountedList #3", "CountedList #4", ".Set up for 0", "Running testInsert()", "Tearing down 0", ".Set up for 1", "Running testReplace()", "Tearing down 1", ".Set up for 2", "Running testOrder()", "Tearing down 2", ".Set up for 3", "Running testRemove()", "Tearing down 3", ".Set up for 4", "Running testAddAll()", "Tearing down 4", "", "%% Time: .*", "", "OK (5 tests)", "", }); } } ///:~

  7. Building with ANT • When a project gets large, it is always needed to automate some tasks. • Typical tasks are: • compiling new or updated code • Packaging class files to a jar file • Running tests • Generating java docs • And so on • This are the typical tasks that ANT help us to manage easily

  8. Using ANT • Ant is available for free both in source code and executable form • It is also integrated into eClipse • To use ant you need to make a build.xml which contains special instruction for ant • This is an xml file with special tags and attributes according to ant specifications

  9. Example of a build.xml file <?xml version="1.0"?> <project name="Thinking in Java (c02)" default="c02.run" basedir="."> <!-- build all classes in this directory --> <target name="c02.build"> <javac srcdir="${basedir}" classpath="${basedir}/.." source="1.4" /> </target> <!-- run all classes in this directory --> <target name="c02.run" depends="c02.build"> <antcall target="HelloDate.run"/> </target> <target name="HelloDate.run"> <java taskname="HelloDate" classname="HelloDate" classpath="${basedir};${basedir}/.." fork="true" failonerror="true" /> </target>

  10. Example of a build.xml file (cont.) <!-- delete all class files --> <target name="clean"> <delete> <fileset dir="${basedir}" includes="**/*.class"/> <fileset dir="${basedir}" includes="**/*Output.txt"/> </delete> <echo message="clean successful"/> </target> </project>

  11. Version control with CVS • CVS keeps code (and other related files) in a repository in a server • The server may be a local area networkd or a server on the internet • Once a CVS server is initialized, team members can get a copy of files on it. If someone connects for the first time, it gets a full copy of all files on the server (current version). However, for later updates he/she gets those that has been updated and also can put his/her update to the server • If some collisions happens before commiting your changes cvs shows you that and you have the chance to correct them • Eclipse supports CVS and is very convenient to use

  12. Logging • We may want to store some useful information during the execution of the program. • Those information may help us to locate bugs in the code or improve software functionality • Logging is much better way than inserting println statements into the code • JDK 1.4 has the logging facility (for previous versions we had to use a framework like “log4j” )

  13. Logging example import java.util.logging.*; public class InfoLogging { private static Test monitor = new Test(); private static Logger logger = Logger.getLogger("InfoLogging"); public static void main(String[] args) { logger.info("Logging an INFO-level message"); monitor.expect(new String[] { "%% .* InfoLogging main", "INFO: Logging an INFO-level message" }); } }

  14. Log levels

  15. Handlers

  16. Debugging • A debuuger helps in stepping through the code, execute statements (one by one or continues upto a breakpoint) • We can display the contents of variables as program proceed • JDK has JDB as a tool which we can use from command line • Eclipse has a sophisticated visual debugger which is very convenient to use

  17. Eclipse debugging

  18. Eclipse debugging (stepping inside)

  19. Profiler • A profiler gathers information that allows you to see which parts of the program consume memory and which methods consume maximum time. • Memory usage data: • Number of object allocations for a specific type. • Places where the object allocations are taking place. • Methods involved in allocation of instances of this class. Loitering objects: objects that are allocated, not used, and not garbage collected. • etc.

  20. Profiler (cont.) • Tracking CPU usage: • The number of times a method was invoked. • The percentage of CPU time utilized by each method. • Total absolute time spent by each method, including the time it waits for I/O, locks, etc. • JDK ships with a profiler named HPROF which we can use for profiling

More Related