Android的SQLite數據庫的測試策略

Question

我在通用新的測試，並試圖找出可以接受的策略進行測試，我使用Android上的SQLite數據庫。

我與我應該這樣做究竟是如何掙扎，不同方法的優劣。

沒有太多的經驗，這似乎是一個很好的方法可能是運行集成測試。 AFAIK這意味着要啓動一個模擬器進行測試，然後運行測試，然後在模擬器上創建和修改數據庫。這種方法聽起來很有吸引力，因爲我可以做一個'往返'測試，從一些預構造的數據對象開始，並且可以使用它們和一個真正的數據庫來測試所有的CRUD操作。這將允許我實際驗證，如果我插入了一個對象然後再讀取它，那進入的POJO與出來的是一樣的。我也可以驗證一些東西，比如對象集合的排序，確認刪除是否真的發生，數據庫升級等等。

我可以設想的一種不同的測試方法包括使用單元測試代替集成測試。我可以設想這些測試涉及驗證是否正確創建了ContentValues對象或確保給定某個Cursor對象POJO已正確創建。

對我來說，好像集成測試方法是優越的，因爲它會提供良好的測試覆蓋率，我寫的CRUD代碼是正確的，這樣我就不會遇到我期望的對象字段被填充，但它是空的，或類似的東西。

什麼其他人做測試Android上的SQLite的代碼？

誰能幫助我理解的單元測試與集成測試的優點，當涉及到的SQLite在Android？

Answer 1

由於SQLite的非Android正在實施，本地單元測試不會對大多數連接到它的代碼的工作。因此你需要運行一個儀器化的單元測試。但這並不意味着你需要編寫真正的集成測試。

您可以使用Instrumentation本身的上下文來創建您正在測試的數據庫。對於這一點，一些JUnit4方便您的gradle這個文件中定義

testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" 

，並使用InstrumentationRegistry.getContext()訪問上下文。

這樣做的好處是，它也適用於圖書館測試而不是檢測任何實際的應用程序，或只是不在文件的上下文中。

由於Android JUnit4 Testing - Where to get Context from?你也可以使用

new RenamingDelegatingContext(InstrumentationRegistry.getTargetContext(), "test_"); 

，並在自己的應用程序的情況下測試的數據庫。