问题
I have an Android app with over 50 Espresso test cases. Most of the time the tests work correctly, but during some runs, one test case (only one) fails with a missing database table. All the other test cases use this table correctly. Sometimes the error message is different, such as:
android.database.sqlite.SQLiteDiskIOException: disk I/O error (code 522 SQLITE_IOERR_SHORT_READ)
Code samples available on request, but it's a massive app so I doubt I could fit it all into a post.
Should I just replace the tablet with one that doesn't throw my bits away?
Another suggestion is I can warm up a Virtual Android Device and see if the error happens there.
Nope - the error also happens, occasionally, on a virtual tablet. Presumably with expensive ThinkPad storage, not with my cheap ONA tablet's storage.
The reason I can't post source for this (it's just by-the-book Espresso and Room code doing it) is when my app was small the problem didn't happen. Only growing the app allowed the problem to occur.
The test database uses a real file, in the getExternalFilesDir() folder; not the in-memory database. And switching to the getFilesDir() folder didn't fix the SQLite file corruption bugs. (I don't have a mounted SD card anyway.)
But lookie here, in the builder for the database: buildee.allowMainThreadQueries().
回答1:
As you give very little details about the code or tests it is hard to answer BUT
I would check the running order of the tests to see if that is different when it fails as your the App might not be in the state you think it should be when the test fails. You could add some pre activity setup to make sure the database is in the right state to run the test which randomly fails.
回答2:
Please refer the link which is help you. And Have you use External Storage directory in your project?
If yes then follow this.
In my opinion there are two possibility:
- Maybe the file system on the device have some problem.
- Your App was in external storage directory, and the SD card was removed or not plenty of space in the testing phone using this App that's why SQLite throw this error.
I hope it will help you....!
回答3:
When you have a bug where corruption comes and goes, and appears in different forms, you have a race condition. So who is racing?
Android Espresso, following the Java ecosystem's penchant for thread abuse, runs its tests in a thread separate from the Android UI thread. (That breaks the rule "UI tests should treat UI objects like objects.")
But if the database is running IN that thread, then the tests' assembly code, creating database objects to test, is racing with the UI thread.
The solution is run as many tests as possible inside @UiThreadTest. And that requires throwing away all the Espresso onView() BS and just accessing view objects directly.
Per Room not creating database in UI-Tests , sprinkling some db.close() around the code also helped.
Switching the tests to use Room.inMemoryDatabaseBuilder() also seems to be helping.
The outer question remains: Has anyone written Espresso tests that called a Room database until smoke rolled out of their device like this before? Or am I really the first?
来源：https://stackoverflow.com/questions/58476757/e-testrunner-android-database-sqlite-sqliteexception-no-such-table-censored