cosa testare l'unità, nelle app Android

Question

Le mie app sono principalmente GUI che comunicano su un server per la maggior parte delle loro informazioni. Se qualcosa va storto di solito sarà nella chiamata di rete o fare un presupposto errato su un oggetto JSON.

I test di unità non sono validi per queste attività correlate alla rete e all'I/o, altrimenti non saranno chiamati test unitari.

SO Sto cercando di raccogliere il punto dei test unitari nel mio caso. Perché dovrei provare se un pulsante Android può fare clic o un EditText può vedere ciò che scrivo? Io proprio non capisco l'utilità di questi test implementating noiosi

private void initElements(){ 
    placeButton = (Button) findViewById(R.id.currplace); 
    placeButton.setText(MainActivity.this.getString(R.string.findingLocation)); 
    placeButton.setEnabled(false); 
    selectplaceLayout = (LinearLayout)findViewById(R.id.selectplaceLayout); 
    selectplaceLayout.setVisibility(View.GONE); 
    splash = (RelativeLayout)findViewById(R.id.splashbg); 
    infoLayout = (LinearLayout)findViewById(R.id.infoLayout); 
} 

se questo metodo di cui sopra passata, che tutte le mie attività eseguite in onCreate, allora so funziona l'applicazione. Un test unitario di questo sarebbe una cosa ridondante in termini di tempo da creare. Che richiede molto tempo perché non ho familiarità con tutti i metodi nel framework di testing jUnit e Android.

quindi, per farla breve, qual è il punto? C'è un modo particolare in cui dovrei pensare a questi test? Tutti gli esempi e le esercitazioni che ho visto finora parlano solo degli esempi più semplici, per brevità, ma non riesco a pensare ad alcun utilizzo pratico per i test unitari in un'applicazione prevalentemente client-server.

Che cosa mi sarei aspettato di scoprire accedendo alle visualizzazioni Android che già conosco che ho dichiarato e inizializzato? Devo pensare a questo in un modo troppo limitato

così, l'intuizione apprezzato

Answer 1

Ci sono un sacco di sfaccettature in tua domanda, ma a mio parere - che probabilmente non ho bisogno di unità di test nel progetto.

I test unitari brillano davvero quando hai bisogno di molte logiche di business per il tuo progetto. In questo caso, probabilmente si desidera suddividere l'applicazione in più livelli (ad esempio, l'architettura a 3 livelli) per aggiungere, tra l'altro, un isolamento naturale per il livello della business logic e coprirlo con una rete di sicurezza dei test unitari.

Questo rete di sicurezza copre il culo durante il refactoring dello strato di business, e questa è una delle cose principali che cosa da test di unità (TDD può offrire alcune belle effetti collaterali aggiuntivi però).

Tuttavia, non tutti gli unicorni e arcobaleni e unità di test possono costare, e talvolta costano molto. I buoni test unitari sono isolati (cioè si tratta di piccoli pezzi di codice). Ciò significa che devi aggiungere strati di astrazione per mettere alla prova le tue classi.

Questo potrebbe avere un effetto positivo sul sistema o negativo. La stratificazione rende il sistema più flessibile con costi di maggiore complessità.

Detto questo - il valore dei test di unità è proporzionale alla quantità di business logic astratta che si intende introdurre nel progetto. Potresti pensarci anche in questo modo - se è eccessivo aggiungere strati astratti alla tua architettura - non aggiungere test unitari - renderanno le cose solo più complicate (architettura e build wise).

In base alla descrizione, l'app tipica tende ad essere praticamente un livello di presentazione per alcuni server esterni. Non si limita a presentare informazioni sul telefono Android e trasforma le azioni dell'utente in comandi sul lato server dove viene eseguita la logica di business principale (controllo).

Con questo approccio la maggior parte del codice che probabilmente scrivi è correlata a "come visualizzare questo e quello" o "come segnalare il server in questo e quel caso". Questo tipo di codice è ovviamente fortemente dipendente dalla piattaforma e questo significa che se vuoi metterlo sotto test devi prendere in giro un sacco e un sacco di codice \ comportamento specifico per Android.

Ora, Android è una piattaforma un po 'specifica. È stato progettato per ottimizzare le prestazioni e consentire agli sviluppatori di avviare e produrre rapidamente le app. Spesso questo significa un certo numero di classi "swiss-knife" che hai usato \ estendere e generalmente questo velocizza la scrittura del codice, ma prendere in giro quelle lezioni può diventare un vero inferno. Per non parlare del fatto che devi capire come funziona la piattaforma sotto il cofano per rendere quei finti utili. In altre parole sovraccarico dal fare quei test sarà alto.

Un'altra cosa che non va nel testare i livelli di presentazione è che tendono a cambiare molto più dinamicamente dei livelli aziendali. E, naturalmente, questo significa che dovrai refactoring test che aggiunge ancora più overhead.

Devo dire una cosa su varie classi di utility/helper. Anche se queste classi appartengono al livello di presentazione e dipendono dal codice Android, ma fanno una logica non banale e è facile prendere in giro e scrivere test di unità per loro, potrebbe essere una buona idea farlo. Tuttavia, se si dispone di un sacco di tale codice, questo potrebbe essere un segnale che non si è progettata la propria architettura/stratificazione e occorre ripensare a ciò che si sta facendo.

Alla fine di rispondere alla tua domanda si deve rispondere a queste domande prima:

sarà sovraprogettazione aggiungere livello astratto che è separato dalla piattaforma alla vostra applicazione (sembra che nel tuo caso lo faccia) ? Se sì, non utilizzare i test unitari, ti rallenteranno solo. Se no, usali.

Hai intenzione di refactoring molto? Se si tratta di un progetto di grandi dimensioni con tanto codice e quindi manutenzione, probabilmente lo farete, quindi investite in stratificazione e unit test (ma, a prima vista, non sembra che questo sia il vostro caso). Se non è il tuo caso, non preoccuparti dei test unitari e vai veloce.

Hai bisogno di prendere in giro la piattaforma molto per scrivere i test di unità? Se sì (sembra essere il tuo caso) - non scrivere test unitari - non ne vale la pena.

Spero che questo possa essere d'aiuto.