CSc 221 Spring 2007 JUnit and String Tips

Half of you are working on JUnit testing of the square root of 2 computation. I, as your client, have received a number of inquiries about the homework. Here are a few ideas, and some sample code for you to experiment with. We will talk about this in class/have talked about this in class. This is quite educational, and JUnit isn't the only Good Stuff. Cool.

• Be aware of how many methods there are. See:

  http://www.sunspotworld.com/javadoc/junit/framework/Assert.html
  
  Remember that the signature of a method includes the number and type of its arguments, so assertEquals with two Strings is a different method--to the compiler--than assertEquals with two doubles, which, in turn, is different from assertEquals with three doubles (the third one being a delta).
   

• You are going to be comparing two strings. Read up on the String class; Java and C++ handle strings quite differently, and this is no accident: the Java designers were trying to get away from ugly things that can happen, by accident or malicious design, with C++ strings. A readable overview: http://www.scit.wlv.ac.uk/~jphb/java/arrays.html It's a bit long; you don't have to read it all to get a lot of insight.
• Key point: strings in Java are immutable. Any time you find yourself thinking that you have modified a string, say to yourself: "Stop! I didn't modify a string; can't be done in Java; maybe I created a new string." The SCJP exam goes crazy over this; a few statements can generate a dozen strings, and you are expected to know when each one is garbage-collectable.
• If you need what looks like modifying a string, look up the StringBuffer class.

Here's some code. Copy it into Eclipse and play with it. Half an hour's experimentation will be time well spent. You will likely lose formatting; select all (Ctrl-A) and reformat Ctrl-Shift-F puts the code into the Sun standard format. You can customize to suit your preference, of course.

// DDM 3.13.2007 check out and demo JUnit issues

package hw3;

import junit.framework.TestCase;

public class JUnitTesting extends TestCase {
    // The name of the next method doesn't matter, but must begin "test.." Hmmm.
    public void testABCXYZ() {
        int goodDecimals = 4; // The number of places after the dec pt that are correct
        String expected1 = "1.9999";
        String expected2 = "2.0000";
        String actuala = "1.99993836523848787787687686232348233487623842384687";
        String actualb = "2.00008978787849723487246232348233487623842384687";  
        // The "2" in next takes into account "1.", and what endIndex means in the API
        // If your answer is OK, one of next two will succeed
        // You pick one, depending on whether convergence is from above or below
        // _I think_ that if your starting guess is larger than the square root, all
        // new approximations will be larger than the true value,
        // _using rational arithmetic._
        // I showed you that with doubles this cannot be depended upon.
        String actualChoppeda = actuala.substring(0, goodDecimals+2);
        assertEquals(actualChoppeda, expected1);

        String actualChoppedb = actualb.substring(0, goodDecimals+2);
        assertEquals(actualChoppedb, expected2);

        // Tbe next two are equivalent; both fail or both succeed
        assertEquals(actualChoppeda, expected1);
        assertEquals(expected1, actualChoppeda);
        // Now experiment with doubles
        assertEquals(2.0, 2.000);
        assertEquals(2.0, 1.0 + 1.0);
        // But this won't work. Why?
        // assertEquals(1.3, 2.01 - 0.71);

        // Uncomment this. Why does it fail?
        // assertEquals(2.0, Math.sqrt(2.0) * Math.sqrt(2.0));
        // System.out.println(Math.sqrt(2.0) * Math.sqrt(2.0));
    }
}
 

Back to the top of the Spring 2007 CSc 221 page

Back to Dan McCracken's Home Page