Tests instrumentaux sur MLKit (test d’intégration)

Les tests instrumentés s’exécutent sur des appareils Android, qu’ils soient physiques ou émulés. En tant que tels, ils peuvent tirer parti des API du framework Android. Les tests instrumentés offrent donc plus de fidélité que les tests locaux, bien qu’ils s’exécutent beaucoup plus lentement.

Configurer votre environnement de test

Dans le fichier build.gradle de niveau supérieur de votre application, vous devez spécifier ces bibliothèques en tant que dépendances :

android {
defaultConfig {
 testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
 }
}

dependencies {
 androidTestImplementation “android.test:runner:$androidXTestVersion”
 androidTestImplementation “androidx.test:rules:$androidXTestVersion”
}

Un projet typique dans Android Studio contient deux répertoires qui contiennent des tests en fonction de leur environnement d’exécution. Organisez vos tests dans les répertoires suivants comme décrit :

• (androidTest) : Le répertoire androidTest doit contenir les tests qui s’exécutent sur des appareils réels ou virtuels. Ces tests incluent des tests d’intégration, des tests de bout en bout et d’autres tests où la JVM seule ne peut pas valider la fonctionnalité de votre application.
• (test) : Le répertoire de test doit contenir les tests qui s’exécutent sur votre machine locale, tels que les tests unitaires. Contrairement à ce qui précède, il peut s’agir de tests qui s’exécutent sur une JVM locale.

AndroidJUnit4

Nous allons maintenant intégrer AndroidJUnit4 pour les tests instrumentaux.

UNE testeur est un composant JUnit qui exécute des tests. Sans testeur, vos tests ne fonctionneraient pas. JUnit fournit un exécuteur de test par défaut que vous obtenez automatiquement. @RunWith échange ce testeur par défaut.

Le AndroidJUnit4 test runner permet à AndroidX Test d’exécuter votre test différemment selon qu’il s’agit de tests instrumentés ou locaux.

Le test comporte trois annotations :

1.@Before : c’est là que va tout le code de configuration pour configurer des composants tels que Viewmodel, Repository, base de données, contexte d’application, etc.

2.@Close : c’est l’endroit où nous fermons vos ressources que nous utiliserons pour tester comme les bases de données, les fichiers, etc.

3.@Test : c’est ici que nous écrivons notre test que nous voulons vérifier et affirmer. Toutes les instructions de test se terminent par Assert.

@RunWith(AndroidJUnit4::class)
class IntegrationTestMLKit {
 private var mSelectedImage: Bitmap? =link null
 private var image: InputImage? = null
 private lateinit var viewModel: SearchViewModel
 private lateinit var repo: DrugRepository
 private lateinit var db: AppDatabase
 private val drugAPI = RetrofitInstance.api


 @Before
 fun setup() {
 val appContext = InstrumentationRegistry.getInstrumentation().context
  mSelectedImage = getBitmapFromAssets(appContext, “zyrtec.jpg”)
 image = InputImage.fromBitmap(mSelectedImage!!, 0)
 db = Room.inMemoryDatabaseBuilder(
 ApplicationProvider.getApplicationContext(),
 AppDatabase::class.java).allowMainThreadQueries().build()
 repo = DrugRepository(drugAPI, db)
 val dataSource = SearchViewModel(repo)
 viewModel = dataSource
 }

@After
 fun closeDb() {
 db.close() }

* Function to test the Text scanner
 */
 @Test
 fun testTextScanner() {
 val rawValue: MutableLiveData<String> = MutableLiveData<String>()
 val recognizer = TextRecognition.getClient(TextRecognizerOptions.DEFAULT_OPTIONS)
 recognizer.process(image!!)
 .addOnFailureListener { e -> 
 e.printStackTrace()
 }
 .addOnCompleteListener {
 if(it.isSuccessful) {
 it.result?.text?.let { itr -> rawValue.value=itr }
 }
 }
 rawValue.getOrAwaitValue()?.let {
 integrateSearchText(it)
 }}

Dans le code ci-dessus, nous stockons les données de TextRecognition dans rawValue Livedata. InstrumentationRegistry.getInstrumentation().context est utilisé pour fournir le contexte de l’application que tous les composants peuvent utiliser. rawValue.getOrAwaitValue() : getOrAwaitValue() est une fonction pour les données en direct qui attend jusqu’à ce que Livedata (rawValue) ait une valeur à l’intérieur.

 private fun integrateSearchText(text: String) {
 var result: String
 val expected = “cetirizine hydrochloride”
 println(“text $text”)
 viewModel.getapproximateTerm(text)
 viewModel.suggestionList.getOrAwaitValue().let {
 result = it.suggestionGroup.sulinkggestionList.suggestion.toString()
 result = result.drop(1).dropLast(1)
 }
 println(“api $result”)
 assert(result.contains(expected))
 }

Dans la fonction ci-dessus integratedSearchText(text: String), nous vérifions la réponse que nous obtenons de l’appel api suggestionList et la faisons correspondre avec le résultat attendu. La fonction assert est utilisée pour vérifier si le test a réussi ou échoué.

Vous trouverez ci-dessous l’implémentation de la fonction getOrAwaitValue(). Vous pouvez modifier getOrAwaitValue selon vos besoins.

import androidx.lifecycle.LiveData
import androidx.lifecycle.Observer
import java.util.concurrent.CountDownLatch
import java.util.concurrent.TimeUnit
import java.util.concurrenapp/build/reports/androidTestst.TimeoutException

fun <T> LiveData<T>.getOrAwaitValue() : T{
 var data: T? = null
 val latch = CountDownLatch(1)
 val observer = object : Observer<T> {
 override fun onChanged(t: T) {
 data = t
 this@getOrAwaitValue.removeObserver(this)
 latch.countDown()
 }
 }
 this.observeForever(observer)
 try {
  if (!latch.await(18, TimeUnit.SECONDS)) {
  throw TimeoutException(“Live Data Never gets its value”)
  }
 }
 finally {
 this.removeObserver(observer)
 }
 return data as T
}

C’est une méthode assez compliquée. Il crée une fonction d’extension Kotlin appelée getOrAwaitValue qui ajoute un observateur, obtient la valeur LiveData, puis nettoie l’observateur – essentiellement une version courte et réutilisable du code observeForever présenté ci-dessus. Lisez le lien ci-dessous pour plus d’informations lien.

Les résultats des tests sont stockés dans le dossier app/build/reports/androidTests.

Dans le dossier, vous trouverez un fichier index.html.

Dans index.html, vous trouverez un résumé de tous les tests que vous avez exécutés.

Tester une application Android était une tâche difficile, mais avec l’aide de AndroidJUnit4nous pouvons rapidement écrire des cas de test pour notre application Android.

Lis ça lien pour mettre en place et comprendre quelle architecture de test nous devrions suivre.