E/TestRunner:android.database.sqlite.SQLiteException:否这样的表:删节(代码1 SQLITE_ERROR) [英] E/TestRunner: android.database.sqlite.SQLiteException: no such table: Censored (code 1 SQLITE_ERROR)

问题描述

我有一个Android应用程序，其中包含50多个Espresso测试用例.大多数情况下，测试可以正常工作，但是在某些运行中，一个测试用例(只有一个)失败，并且缺少数据库表.所有其他测试用例均正确使用此表.有时错误消息是不同的，例如:

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?

另一个建议是，我可以预热虚拟Android设备，看看是否在那里发生错误.

Another suggestion is I can warm up a Virtual Android Device and see if the error happens there.

否-错误有时也会在虚拟平板电脑上发生.大概是使用昂贵的ThinkPad存储设备，而不是使用我便宜的ONA平板电脑的存储设备.

Nope - the error also happens, occasionally, on a virtual tablet. Presumably with expensive ThinkPad storage, not with my cheap ONA tablet's storage.

我之所以无法发布源代码(仅仅是按书写的Espresso和Room代码)的原因是，当我的应用很小时，问题就没有发生.仅通过扩展应用程序，问题才可以发生.

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.

测试数据库在getExternalFilesDir()文件夹中使用真实文件；不是内存数据库.并且切换到getFilesDir()文件夹并不能解决SQLite文件损坏的错误. (反正我没有安装SD卡.)

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.)

但是在这里，在数据库的生成器中:buildee.allowMainThreadQueries().

But lookie here, in the builder for the database: buildee.allowMainThreadQueries().

推荐答案

当您遇到一个错误时，腐败会不断出现，并且以不同的形式出现，则您处于竞争状态.那谁在比赛?

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遵循Java生态系统的线程滥用倾向，在与Android UI线程不同的线程中运行其测试. (这违反了"UI测试应将UI对象像对象一样对待"的规则.)

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.")

但是，如果数据库在该线程中运行，则测试的汇编代码(创建要测试的数据库对象)将与UI线程竞争.

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.

该解决方案在@UiThreadTest中运行了尽可能多的测试.这就需要扔掉所有的Espresso onView() BS，而直接访问视图对象.

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.

每个房间未在UI测试中创建数据库，围绕代码的一些db.close()也有所帮助.

Per Room not creating database in UI-Tests , sprinkling some db.close() around the code also helped.

将测试切换为使用Room.inMemoryDatabaseBuilder()似乎也有帮助.

Switching the tests to use Room.inMemoryDatabaseBuilder() also seems to be helping.

外部问题仍然存在:是否有人编写过称为Room数据库的Espresso测试，直到烟雾像以前那样从设备中喷出?还是我真的是第一个?

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?

这篇关于E/TestRunner:android.database.sqlite.SQLiteException:否这样的表:删节(代码1 SQLITE_ERROR)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！