jim xu

I had a hard time to figure out how to do a unittest for a method. Need some help here..

some other import...; import com.foo.bar.Cell; import com.foo.bar.SQLDatabase; import com.foo.bar.SQLDatabaseHelper; import com.foo.bar.util.Log; class DBHelper extends SQLDatabaseHelper { some other methods... @Override public ArrayList<Cell> fetchRows() { List<Cell> celllist = new ArrayList<Cell>(); try { SQLDatabase db = openDatabase(name); } catch (SQLDatabaseException e) { Log.e("Open SQL database failed", e.toString()); return null; } if (db != null) { for(Row r : db.iterator()) { celllist.add(new Cell(r)); } } return celllist; }

So basically, I want to unittest the fetchRows method for this class (snippet stripped off a bit in order to just show the problem). The Log class is provided by vendor's API and its a final class. I can't change it. The problem is the 'e' method requires a specific device console to establish and its a native code. In unittest environment, it just throws UnsatisfiedLinkError because there isn't such device there. I am thinking to use another mock logging class to replace the Log during runtime so that it wouldn't puke. (Like a duck typing in python) But I don't know how to do this in Java.

For example, if in python, it would be something like:

import com.foo.bar.util.Log import DBHelper class MockLog(object): def e(header, msg): pass def testFetchRows(): DBHelper.Log = MockLog; helper = DBHelper(); helper.fetchRows();

I'd agree that 1 and 2 are far worse than 3. If a field is private and you have public method to send the field out of the object scope, that private constrain becomes just meaningless and its a bad habit. Keep private as private, provide a wrapper method (adapter design pattern) to access them is the right way to go.

Since the object created is Bar's object, so "this" should reference to the Bar's object. And because the method is overridden, Bar object has no visibility of Foo's show. Try change the signature of the method for foo and call it from Bar's object, you will see that it actually calls Foo's show again, in that case these two shows become just two different methods (happened to have the same name) Interesting enough is that changing the access level can also change the calling sequence.

[ March 04, 2008: Message edited by: jim xu ]
[ March 04, 2008: Message edited by: jim xu ]

Ah I see. Thanks!

I found that java does not seem to have a very reliable way to do date/time comparison. Inspect the following sample code:
Calendar cal1 = Calendar.getInstance(); Calendar cal2 = Calendar.getInstance(); cal1.set(2008, 8, 15, 8, 30, 0); cal2.set(2008, 8, 15, 8, 30, 0); System.out.println("cal1 time is " + cal1.getTime()); System.out.println("cal2 time is " + cal2.getTime()); System.out.println("cal1 time milli is " + cal1.getTimeInMillis()); System.out.println("cal2 time milli is " + cal2.getTimeInMillis()); System.out.println(cal1.getTime().compareTo(cal2.getTime()));
You probably would think that the date/time and millis returned by these two calendar should always be the same thus the compare result should always 0, but in fact, it doesn't. Sometimes it returns 0 sometimes -1... I spent a hack of time to find out this problem in my code (due to I wasn't even thought it could be wrong)

Here is a sample output:
cal1 time is Mon Sep 15 08:30:00 PDT 2008 cal2 time is Mon Sep 15 08:30:00 PDT 2008 cal1 time milli is 1221492600687 cal2 time milli is 1221492600688 -1
the second one calc'ed 1 millisecond more. So if this isn't the prefer way to compare time in Java, what should I use?

Thanks!
[ March 02, 2008: Message edited by: jim xu ]

In terms of the class member, protected means only the inherited classes can see those members. The package access for class is somewhat like that. Only classes inside the same package can see that class. So can we treat the default 'package access' for a class like a 'protected' class?