2015-08-12 15 views
16

Ci sono due opzioni disponibili per eseguire unit test in Android Studio:qual è il modo più veloce per eseguire unit test in Android

  1. Fare clic destro sul file con il test di unità (che è Gradle-Aware Make).
  2. testAppDebugUnitTest l'attività è dall'elenco delle attività Gradle disponibili.

Il primo in realtà consiste di due compiti: - :app:assembleAppDebug e :app:assembleAppDebugUnitTest

La seconda è solo testAppDebugUnitTest sé.

Il primo è un modo recommended dal team di Google Tools, ma richiede il doppio del tempo rispetto al secondo.

Non c'è alcuna differenza visibile su come eseguire i test unitari eccetto la durata. Potresti pensare che il tuo codice non verrà compilato senza assembleAppDebug, ma questo non è vero - le modifiche introdotte a una delle due classi sotto un test o un test stesso compilato ed eseguito come previsto.

Quindi, qual è la differenza e perché è il modo consigliato se impiega il doppio del tempo per preparare tutto prima dell'esecuzione dei test delle unità reali?

+0

In genere mi sono abituato a fare jUnit Test con Android Studio. Rende i file html/css che mostrano il test di successo o di fallimento: http://blog.element84.com/easy-testing-with-android-studio.html – Maga

risposta

12

Non ho molta esperienza di lavoro con Gradle, ma ovviamente è sempre meglio usare gli strumenti consigliati dal team di Google al posto di altri.

ci vuole il doppio del tempo rispetto al secondo.

Se si utilizza il nuovo sistema di Gradle con Android (o Android Studio) costruire si potrebbe avere capito che anche il più semplice chiamata Gradle (ad esempio Gradle progetto o attività grade) è piuttosto lento.

Per evitare questo tempo, prendere i processi in Android Studio è necessario Speed up Gradle build time. Sarà sicuramente fa la differenza

Ecco alcuni passi per accelerare il Gradle costruire tempo >>

  • In impostazioni del compilatore (Studio Android -> Preferenze -> Progetto impostazioni [vostro progetto] -> Compilatore (Progetti Android basati su Gradle)), tipo --offline nella casella "Opzioni della riga di comando".

    da ~ 4 minuti a ~ 20 secondi.

enter image description here

  • In un altro modo, è possibile ridurre questo tempo di avvio di Gradle (sul mio computer fino a due secondi), se dite Gradle di usare un demone per costruire. Basta creare un file chiamato gradle.proprietà nel seguente elenco:
    • /home/<username>/.gradle/ (Linux)
    • /Users/<username>/.gradle/ (Mac)
    • C:\Users\<username>\.gradle (Windows)

Aggiungi questa linea al file:

org.gradle.daemon=true 

Da ora in poi Gradle userà una piazzetta mon da compilare, indipendentemente dal fatto che tu stia utilizzando Gradle da riga di comando o edificio in Android Studio. È inoltre possibile inserire il file gradle.properties nella directory principale del progetto e trasferirlo nel sistema SCM. Ma dovresti farlo, per ogni progetto (se vuoi usare il demone in ogni progetto).

Nota: Se non costruire nulla con Gradle per un certo tempo (attualmente 3 ore), si fermerà il demone, in modo che potrete godere di un tempo di start-up a lungo alla generazione successiva.

Per ulteriori informazioni si prega di consultare questo Building and running app via Gradle and Android Studio is slower than via Eclipse

miglioramenti delle prestazioni sono uno dei grandi compiti della tabella di marcia per il 2015 Gradle (e raggiungendo in 2016). Quindi spero, vedremo le prestazioni generali aumentare in questi anni.

n g + c'è uno discussion con gli sviluppatori a riguardo.

Spero che questa informazione ti sia di aiuto.

+2

Grazie per una risposta così esaustiva, sfortunatamente, questo non è quello che ho ve chiesto. – Eugene

+0

Sì !! Ovviamente so che questa non è una risposta alla domanda (sono pronto a menzionare la stessa cosa nella mia risposta) ma aiuta qualcuno a risolvere il problema simile :) –

+0

Nelle ultime versioni di Android Studio org.gradle.daemon = true è abilitato per impostazione predefinita –

4

Il motivo per cui l'opzione 1 richiede il doppio del tempo è perché la maggior parte del tempo è sprecata per far girare Gradle e controllare se le attività sono aggiornate. Quindi eseguire un assemblaggio non-operativo lo renderà due volte più lungo. Puoi verificarlo eseguendolo da solo e controlla il tempo perso facendo un no-op.

Con gradle, l'esecuzione con "--offline --daemon --parallel" può portarti da qualche parte (offline è utile quando hai un accesso lento a repository Maven/JCenter, daemon è utile per mantenere i file nella cache e in parallelo è particolarmente utile se disponi di MultiDex e hai diviso la tua app in piccoli moduli)

Se ti stai chiedendo semplicemente "Qual è il modo più veloce per eseguire i test delle unità in Android?" senza considerare il cambiamento che avresti bisogno, ti consiglio di passare a Buck (https://buckbuild.com/), che è 10 volte più veloce di Gradle nei test di dex-xing e spinning, ma ha un supporto AS limitato.

Problemi correlati