We've just gone through a fairly lengthy, but successful, exercise in not only converting our data from XML to SQLite, but also incorporating frequency of use into it. However, before we start adding features based on these advantages, it's time to consolidate our gains and make sure we're in good shape. We have several things on our plate, as follows:
1) It turns out that when it's hiragana only, the kanji isn't showing in the question. This is an issue that had been resolved with the XML database, and now has re-appeared. That will be a quick fix.
2) A tricker one is a test failing which proves the kanji display matches the database, first on a non-match then a null-pointer exception. This is purely due to test code, which involves getting a couple of paramaters fed into the subclass of the application object.
3) I need to take a little time out to figure out how to determine how much space my app is taking up, whether it's loaded into onboard memory or the SD card, and if I can delete the database file once the database has been loaded.
Let's tackle the second one first. It might involve implications for test 1.
Let's run it again:
junit.framework.ComparisonFailure: expected:<青> but was:<以内>
And again:
junit.framework.ComparisonFailure: expected:<青> but was:<>
and again:
junit.framework.ComparisonFailure: expected:<青> but was:<湯>
While the null pointer doesn't seem to be repeating, it's clear that my setting of the app object is happening to late. Let's move it to before the getActivity in setup. No, that won't work because we need activity to get the context; but what if I get the activity *again* after setting the app object? Will the app object persist state through the next getActivity? May be...
Nope: junit.framework.ComparisonFailure: expected:<青> but was:<高等学校>
My working theory is that the quiz sequence, which is created in previous test, exists already when the app is started, and that's generated randomly. But, since I'm setting the question retrieval parameters directly into the application object, and it's using those, why is it being lost? Are they not looking at the same app object?
When I extract the values and display them in logcat for the unit test, they are correct. Let's dump the values the program has as it runs.
Not surprisingly, they are different. It must be because when I recreate the activity, it's somehow re-instantiating the context? Hard to say. I'm going to drop it for now and come back to it. Time's a wastin'. In this case, unit testing didn't help - the ActivityInstrumentationTestCase2 doesn't provide access to the context, and I need that to control the activity. And the application object doesn't appear to be uniform between iterations.
Btw, here's a note I found in stackoverflow regarding the speed of tests while researching the other problem:
"I noticed that when testing plain Java classes via test classes derived from TestCase and AndroidTestCase, LogCat output disappears.
Is it possible to still capture the output of these messages? or my only recourse is to use the much more sluggish ActivityInstrumentationTestCase2<> as a base class?"
So, if I could free myself of ActivityInstrumentationTestCase2, I could speed up the tests. It's not an issue now, but it could become that way.
Ok. I'm a bit frustrated I couldn't get that test to work. Maybe this one will be kinder to me. Well, now, it's kind of the same problem. To test if the hiragana gets displayed, I need to update the applicationContext and tell it what to tell the activity - something I just failed to do. It turns out that perhaps ActivityUnitTestCase might be a good solution. It's a stand alone test of an activity that allows you to mock a lot of stuff. This is at a cost of extra setup and tear down. l will perhaps tackle this in a future post.
No comments:
Post a Comment