L'approccio corretto per Test unità Android

Question

So che è un argomento noioso per tutti gli sviluppatori Android. Ma qual è esattamente l'approccio corretto per i test Android?

Questo è quello che posso immaginare.

70% Unit testing (JUnit per testare tutta la logica di business, livello di rete, livello di database, ecc ...)

test di integrazione

20% (forse il test contro il server di finto? Testare principalmente risultati API?)

Test dell'interfaccia utente al 10% (prendi in giro qualsiasi altra cosa oltre all'interazione dell'interfaccia utente, molto probabilmente Mockito + Espresso)

È questo che seguono o seguono un altro modello?

Grazie in anticipo!

Answer 1

Questa domanda e la mia risposta, non hanno nulla a che fare con Android in particolare, ma questa è una buona cosa.

Ho leggermente modificato le ipotesi, ma il principio è lo stesso.

• 70% Unit testing (JUnit per testare tutta la logica di business.) Prova

• 20% integrazione (livello di rete, livello di database, ecc, vero server) test UI

• 10% (Flusso di lavoro dell'interfaccia utente + test manuale)

Dovrebbe essere il 70%? 80%? 85%? Non importa. La chiave è il rapporto. Vuoi che la maggior parte dei tuoi test sia fast, isolated in memory tests. Se interagisci con un database, semplicemente vuoi sapere come funzionano le tue query. La query di aggiornamento effettivamente aggiorna l'entità corretta? Infine, controlli che l'interfaccia utente funzioni come previsto. Non importa a questo livello ciò che mostri. Finché la schermata di accesso viene visualizzata quando l'utente non ha registrato la tua multa.

Questo è spesso definito come Test Pyramid ed è quello che hai descritto, ma solo i rapporti esplicativi.