Test nello sviluppo mobile: cosa sono, quali tipi e come organizzarli

Livelli di test: Unit, Integration, E2E

Test unitari

I test unitari sono il fondamento dei test di applicazioni mobili. Verificano la più piccola unità di codice — una singola funzione, metodo o classe in isolamento dal resto del sistema. Nello sviluppo mobile, i test unitari sono scritti in JUnit (Android) e XCTest (iOS). Un buon test unitario deve essere veloce, indipendente e ripetibile — non deve dipendere dalla rete, dal database o dai componenti UI. Per l'isolamento si usano test double: mock, stub e fake.

Mockito (Java/Kotlin) e MockK (Kotlin-first) sono librerie popolari per creare oggetti mock su Android. Su iOS si usano OCMock, Cuckoo o protocolli manuali. Regola: i test unitari dovrebbero coprire la logica di business e i modelli di dati. I test UI non dovrebbero duplicare i test unitari — verificano l'interazione dell'utente con l'interfaccia.

Test di integrazione

I test di integrazione verificano l'interazione tra componenti: repository con database, ViewModel con servizio API, navigazione tra schermate. A differenza dei test unitari, i test di integrazione utilizzano dipendenze reali o vicine alla realtà (ad esempio, database in memoria o server mock). Robolectric è un framework per eseguire test Android su JVM senza emulatore, accelerando i test di integrazione di 10 volte.

I test snapshot (Golden Tests) sono un tipo speciale di test di integrazione che confrontano un componente UI renderizzato con un'immagine di riferimento (snapshot). Se l'aspetto cambia, il test fallisce — lo sviluppatore vede cosa è cambiato. Facebook SnapshotTestCase (iOS) e Shot (Android) sono strumenti popolari per i test snapshot.

Test E2E e UI

I test E2E (end-to-end) verificano lo scenario utente completo dall'inizio alla fine: avvio dell'app, login, esecuzione di un'azione, verifica del risultato. I test UI sono un sottoinsieme di E2E focalizzato sull'interfaccia. Strumenti: Espresso (Android), XCUITest (iOS), Detox (React Native). I test E2E sono i più lenti, quindi vengono eseguiti separatamente su CI — di solito nelle build notturne.

Strumenti iOS: XCTest e XCUITest

XCTest

XCTest è il framework integrato di Apple per i test unitari di applicazioni mobili. XCTestRunner esegue test sul simulatore o su un dispositivo reale. I test ereditano da XCTestCase, contengono setUp e tearDown per preparazione e pulizia. XCTest include XCTAssert per asserzioni (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) e XCTWaiter per attendere operazioni asincrone.

Esempio di un semplice test XCTest: creare un modello User, verificare la correttezza dell'inizializzazione, la formattazione del nome e il calcolo dell'età. Code Coverage in Xcode mostra quali righe di codice sono coperte dai test — l'obiettivo per progetti commerciali: almeno 70–80% di copertura della logica di business. XCTest è integrato con Xcode Server e sistemi CI tramite xcodebuild test.

XCUITest

XCUITest è il framework di Apple per i test UI. Funziona tramite identificatori di accessibilità: XCUIElementQuery trova pulsanti, campi di input, tabelle per label, identificatore o tipo. XCUITest registra una sequenza di azioni (record/playback) e genera codice di test. Importante: tutti gli elementi UI devono avere un accessibilityIdentifier per un funzionamento stabile dei test.

Strumenti Android: JUnit, Espresso, Robolectric

JUnit e Mockito

JUnit è il framework di base per i test unitari di applicazioni mobili in Java/Kotlin. Su Android si usano JUnit 4 (ultima versione stabile 4.13.2) e JUnit 5 per nuovi progetti. Mockito è una libreria per creare oggetti mock: when(mock.method()).thenReturn(value) — un pattern standard per isolare la classe testata dalle dipendenze.

Esempio di un test JUnit per Android:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso e UI Automator

Espresso è il framework di Google per i test UI Android. Espresso si sincronizza automaticamente con il thread UI: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso è facile da scrivere e stabile grazie all'attesa integrata dello stato idle. UI Automator è un framework per test tra applicazioni che può interagire con elementi di sistema (dialoghi di autorizzazione, pannello notifiche).

Strumenti multipiattaforma: Detox, Appium

Detox per React Native

Detox è un framework E2E a scatola grigia per testare applicazioni mobili React Native di Wix. Detox funziona su entrambe le piattaforme da un'unica base di codice di test, utilizzando Espresso (Android) e XCUITest (iOS) internamente. Detox attende automaticamente che l'app diventi inattiva (nessuna animazione, richieste di rete, timer) e solo allora esegue l'azione successiva.

Appium

Appium è un framework multipiattaforma universale che supporta Android, iOS, Web e applicazioni ibride. Appium utilizza il protocollo WebDriver e supporta qualsiasi linguaggio di programmazione (Java, Python, JS, Ruby). Appium Server funziona come un server HTTP che traduce i comandi in comandi nativi UI Automator / XCUITest. Il principale svantaggio di Appium è la velocità: i test vengono eseguiti più lentamente di Espresso o XCUITest nativi.

TDD e BDD: metodologie di test

TDD: Test-Driven Development

TDD è una metodologia di test di applicazioni mobili in cui il test viene scritto prima del codice di implementazione. Il ciclo Red-Green-Refactor: (1) scrivere un test che fallisce (Red), (2) scrivere il codice minimo per far passare il test (Green), (3) rifattorizzare il codice mantenendo il test superato. TDD fornisce una copertura del test al 100% per le nuove funzionalità e un'architettura pulita, poiché il test è la prima specifica del requisito.

BDD: Behaviour-Driven Development

BDD è un'estensione di TDD in cui i test sono scritti in linguaggio naturale nel formato Given-When-Then. Given (contesto) — When (azione) — Then (risultato atteso). I test BDD sono comprensibili a tutti i membri del team: sviluppatori, tester, analisti e clienti. Mock vs Stub vs Fake: Mock verifica l'interazione (se il metodo è stato chiamato), Stub restituisce dati fissi, Fake è un'implementazione di lavoro semplificata (ad esempio, DB in memoria). In IT Sectr, usiamo TDD per la logica di business critica e BDD per gli scenari di accettazione.

Test Doubles è il nome generale per gli oggetti che sostituiscono le dipendenze reali nei test. Esistono quattro tipi: Dummy (oggetto per riempire parametri, non utilizzato), Stub (restituisce valori dati), Spy (registra chiamate per verifica), Mock (predefinisce chiamate attese). Comprendere la differenza è fondamentale per una corretta progettazione dei test.

CI/CD e Device Farm

Automazione dei test in CI/CD

CI/CD — Integrazione Continua e Consegna Continua: la pratica di costruire e testare automaticamente le applicazioni mobili a ogni modifica del codice. Nello sviluppo mobile, la pipeline CI/CD include: linting, test unitari, test di integrazione, build APK/IPA e test UI. GitHub Actions e Bitrise sono piattaforme popolari per il CI/CD mobile. I test dovrebbero essere eseguiti rapidamente: test unitari in 1–2 minuti, di integrazione in 5–10, UI in 15–30 minuti.

Device Farm

Device Farm è una fattoria di dispositivi reali per i test. Firebase Test Lab (Android) e Xcode Cloud (iOS) forniscono accesso cloud a centinaia di modelli di dispositivi. Device Farm rivela problemi non visibili sugli emulatori: diverse dimensioni dello schermo, prestazioni su dispositivi vecchi, problemi di compatibilità. In IT Sectr, usiamo regolarmente Firebase Test Lab per Android e Xcode Cloud per iOS.