Test 1

1A - 

just return "" -- sneaky

1B -

just use cell name as a hash key -- don't even think about parsing
into row/column yet

1C -

"cheating" by using Java's Long constructor and checking for
NumberFormatException to tell if it's a number or not -- hey, it works
:-)

=== Part 2

2A -

testManyCells passed right off the bat (?)
 -- oh, right, cause I was already using a hashtable

2B -

passed right off the bat -- cause I didn't trim cause it wasn't a
number... whatever.  Not sure what this is testing.

2C -

doesn't seem to be much difference between getFormula and getLiteral
-- when would they be different?  Seems like a superfluous public
method.

2D -

Tried to use StreamTokenizer but the API sucks. Went back to
StringTokenizer and just ignored parens.  I've seen a lot of 

2E, 2F, 2G, 2H -

Worked OK but I knew it wouldn't last...

2I -

Totally failed until I did a bit of research and found an arithmetic
parser grammar at
http://www.iit.edu/~lee/cs495/samplesrc/javacc/Arithmetic.jj - from
then it was easy -- I wrote a few recursive methods --
evaluateExpression calls evaluateTerm calls evaluateFactor -- with
evaluateFactor checking for paren and re-calling
evaluateExpression... Piece of cake.

2J - errors

Not enough error conditions -- are you going to republish with the
errors from the list?

=== Part 3 

This part was really easy -- took about 35 minutes, plus an hour to
refactor.  Cell references were essentially a one-line feature.

Circular references were a little tougher, but once I realized you can
keep a stack with "all cells I'm in the middle of evaluating" it went
like buttah.