2011-01-16 9 views

risposta

9

L'applicazione di prova "strumenti" l'obiettivo o l'applicazione principale.

La sezione di strumentazione nel progetto AndroidManifest.xml del test consente di eseguire i test nello stesso processo dell'applicazione. Questa funzione di strumentazione consente all'applicazione di test di passare attraverso i cicli di vita dei componenti Android in modo controllato.

Avere questo controllo consente di (ad esempio) di creare test ripetibili per i casi per il ciclo di vita dell'attività (creare, riprendere, mettere in pausa, distruggere).

vedere http://developer.android.com/guide/topics/testing/testing_android.html#Instrumentation

Quindi, in sintesi, l'applicazione in più ha poteri speciali oltre il bersaglio di prova. Poiché questi sono incapsulati nell'applicazione di test, la vostra vera applicazione necessita solo delle autorizzazioni necessarie per svolgere il proprio compito.

+0

Non sono sicuro che questo sia vero, dal mio permesso di esperienza utilizzato nel test deve essere dichiarato nel manifest di test (che è piuttosto scadente se me lo chiedi) – zode64

+0

È vero che alcune librerie di test richiedono che il target abbia permessi extra. Per esempio, penso che Robotium abbia usato il permesso per vedere quali processi sono in esecuzione. Io uso robotium e sono d'accordo sul fatto che non era l'ideale. Tuttavia il robotium non sembra più aver bisogno di questo. Presumo che, dal momento che l'app di test viene eseguita come parte del processo dell'applicazione di destinazione, utilizza le autorizzazioni del target. Puoi essere più specifico della tua esperienza? La mia risposta è alla domanda "perché è stato deciso di spostare i test in un progetto separato". – byeo

+0

Un semplice esempio, ho App A e Test Project B che verifica l'App A.Se voglio usare Internet nel Test Project B per verificare un risultato (lo so, è un test scadente) ma l'App A non ha i permessi internet devo aggiungere l'App A in ogni modo quindi dando un permesso di produzione App non necessario che è sbagliato. visto che il progetto di test ha il suo manifest, sarebbe meglio essere in grado di definire permessi specifici per il test, anche se capisco che a un livello basso sarebbe molto difficile – zode64

0

Penso che in questo modo sia possibile eseguire due app separate, una normale e una per testarla. Se vuoi pubblicare la tua app, non devi dare a tutti i tuoi test. Ma forse è stato fatto per scopi migliori!

+0

Sì, questo è fatto in modo che il codice di prova non è integrato nel l'applicazione stessa, permettendo il codice di test da eseguire rispetto alla versione di produzione finale dell'app senza dover aumentare la dimensione dell'app con tutto il codice di test incorporato. – hackbod

+0

Oh, ricorda che * puoi * compilare i test direttamente nella tua app, non c'è nulla che possa impedirlo. Non ci sono buoni motivi per farlo, dal momento che il codice di prova si collega al codice dell'app in modo da avere pieno accesso ad esso. – hackbod

+1

Tuttavia, nel sito dev di android si afferma che "l'approccio migliore è quello di aggiungere il progetto di test in modo che i test della directory radice/siano allo stesso livello della directory src/del progetto dell'applicazione principale." i test di significato sono incorporati nell'applicazione. – Eugene

1

La documentazione corrente, come io interpreto, afferma che si dovrebbe tenere il codice di prova in un progetto separato in "prove" delle cartelle all'interno del progetto applicaton => "Un progetto all'interno di un progetto"
http://developer.android.com/guide/topics/testing/testing_android.html#TestProjects

Come ?
Creating an Android Test project in Eclipse

Perché?
Invece di ex. 40 progetti hai 20 progetti => panoramica migliore, meno manutenzione, eclissi più veloce.
Due build.xml => più facile CI costruisce con Jenkins
Due file manifesto => future versioni di ADT costruiscono strumenti sosterrà manifesta la fusione

Problemi correlati