Prueba de un proyecto que utiliza ActionBarSherlock
Mi configuración:
- Proyecto de biblioteca: ActionBarSherlock
- Proyecto
- Proyecto de prueba
Mi proyecto tiene el proyecto de biblioteca vinculado como un proyecto de biblioteca. Se compila y funciona bien.
- Instalando PhoneGap, ejecutando el comando de error 'ant'
- Biblioteca resolver a una ruta sin archivo project.properties
- Problema con proguardFile, null devuelto: 1
- ¿Por qué el archivo .bat salta líneas y salta al final?
- Android: falla la compilación de ANT con google-play-services-lib: "resuelve a una ruta sin archivo project.properties para el proyecto"
Ahora trato de probar mi aplicación usando un proyecto de prueba normal. Ejecutar las pruebas en eclipse funciona perfecto. Si intento ejecutar las pruebas con ant, el proyecto de prueba ni siquiera compila:
[javac] LoginActivityTest.java:9: cannot access com.actionbarsherlock.app.SherlockActivity [javac] class file for com.actionbarsherlock.app.SherlockActivity not found [javac] public class LoginActivityTest extends ActivityInstrumentationTestCase2<LoginActivity> { [javac] ^ [javac] LoginActivityTest.java:25: cannot find symbol
Construir a través de eclipse funciona perfecto y la prueba funciona perfecto, también.
Si vinculo el proyecto de biblioteca a mi proyecto de prueba, se compila con ant pero las pruebas fallan.
[exec] Error in testSuiteConstructionFailed: [exec] java.lang.RuntimeException: Exception during suite construction [exec] at android.test.suitebuilder.TestSuiteBuilder$FailedToCreateTests.testSuiteConstructionFailed(TestSuiteBuilder.java:238) [exec] at java.lang.reflect.Method.invokeNative(Native Method) [exec] at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169) [exec] at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154) [exec] at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:537) [exec] at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1551) [exec] Caused by: java.lang.reflect.InvocationTargetException [exec] at java.lang.reflect.Constructor.constructNative(Native Method) [exec] at java.lang.reflect.Constructor.newInstance(Constructor.java:417) [exec] at android.test.suitebuilder.TestMethod.instantiateTest(TestMethod.java:87) [exec] at android.test.suitebuilder.TestMethod.createTest(TestMethod.java:73) [exec] at android.test.suitebuilder.TestSuiteBuilder.addTest(TestSuiteBuilder.java:262) [exec] at android.test.suitebuilder.TestSuiteBuilder.build(TestSuiteBuilder.java:184) [exec] at android.test.InstrumentationTestRunner.onCreate(InstrumentationTestRunner.java:371) [exec] at com.zutubi.android.junitreport.JUnitReportTestRunner.onCreate(JUnitReportTestRunner.java:90) [exec] at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3891) [exec] at android.app.ActivityThread.access$1300(ActivityThread.java:122) [exec] at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1184) [exec] at android.os.Handler.dispatchMessage(Handler.java:99) [exec] at android.os.Looper.loop(Looper.java:137) [exec] at android.app.ActivityThread.main(ActivityThread.java:4340) [exec] at java.lang.reflect.Method.invokeNative(Native Method) [exec] at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) [exec] at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) [exec] at dalvik.system.NativeStart.main(Native Method) [exec] Caused by: java.lang.NoClassDefFoundError: com.myproject.android.app.activities.LoginActivity [exec] at com.myproject.android.app.test.LoginActivityTest.<init>(LoginActivityTest.java:18) [exec] ... 19 more
Mi clase de prueba:
public class LoginActivityTest extends ActivityInstrumentationTestCase2<LoginActivity> { private LoginActivity mActivity; private EditText mTextUserName; private EditText mTextUserPassword; public LoginActivityTest() { // the super call is line 18 (see stack trace above) super("com.myproject.android.app.activities", LoginActivity.class); } @Override protected void setUp() throws Exception { super.setUp(); mActivity = getActivity(); mTextUserName = (EditText) mActivity.findViewById(com.myproject.android.app.R.id.login_activity_username); mTextUserPassword = (EditText) mActivity.findViewById(com.myproject.android.app.R.id.login_activity_password); } public void testPreConditions() { assertTrue("Activity is null!", mActivity != null); } public void testLogin() throws Throwable { mActivity.runOnUiThread(new Runnable() { public void run() { mTextUserName.setText("username"); mTextUserPassword.setText("password"); } }); sendKeys(KeyEvent.KEYCODE_ENTER); } }
Algunas ideas de cómo puedo solucionar esto?
Actualización: parece que la construcción de hormigas / prueba sigue siendo un desastre. Según esta entrada de blog acerca de probar un proyecto de biblioteca, la mayoría de los 7 problemas enumerados se arreglarán en la próxima versión de ADT (ADT r20).
- Script `create` para Cordova Android falla al crear nuevos errores de proyecto con la configuración java / ant
- Problemas de compilación de build.xml en Android SDK con procesamiento
- Biblioteca de Android - cómo ensamblar jar con dependencias usando gradle?
- Múltiples paquetes de aplicaciones Android .APK de código fuente único
- Cordova add platform - Error al ejecutar el comando 'ant'
- Comando linux "android": ¿equivalente en Windows?
- Prueba de unidad automatizada para Android / Ant
- Construyendo una aplicación para Android de la hormiga a través de Hudson - problema de pollo y huevo
Hay un montón de diferentes bits de información flotando alrededor de la utilización de proyectos de la Library
desde ADT 17 rompió / arregló todo (dependiendo de si usted está golpeando su cabeza contra su escritorio).
En primer lugar, tenga en cuenta la diferencia entre Library
y "library" donde Library
es un nombre según lo decretado por el equipo de Android. También estoy utilizando el proyecto de Referencing
que describe un proyecto que utiliza un proyecto de Library
.
Es decir, un proyecto de Referencing
utiliza un proyecto de Library
.
No Library
"biblioteca" Proyectos
En el desarrollo normal de Java es posible vincular proyectos en Eclipse donde uno depende del origen del otro. Creo que este enfoque tiene el efecto de usar la fuente de los proyectos de biblioteca como fuente para el proyecto de referencia. Esto significa que el origen de los proyectos de biblioteca está en el ámbito mientras compila el proyecto de referencia. Las clases del proyecto de la biblioteca se construyen al mismo tiempo que las del proyecto referenciador.
Al construir para su uso en la mayoría de las situaciones esto funciona perfectamente bien como todas las clases se construyen y luego se envasan en JARs o WARs o lo que sea.
Proyectos de biblioteca
Un enfoque competitivo ( no una mezcla y un partido) para proyectos de biblioteca son los proyectos de la Library
equipos de Android:
Un proyecto de Android marcado como un proyecto de Library
compilará y construirá sus fuentes en un archivo jar
en su directorio bin
(después de un comando clean / build). Cualquier proyecto de Referencing
importa automáticamente este jar
y accede a la funcionalidad de proyectos de la Library
. Puede ver esta relación mirando dentro de Android Dependencies
Java Library Android Dependencies
en el Explorador de paquetes.
Junto con la resolución de dependencia de clase, el recurso también está siendo directamente referenciado y compilado en archivos R.java
dentro del directorio Referencing
proyectos gen
.
El nuevo ADT
introdujo problemas a las personas establecidas porque agregó "soporte" para incluir jarras que fueron referenciadas por el proyecto Library
:
Pre ADT 17
El proyecto de la Library
tenía un tarro añadido a su ruta de construcción. El proyecto de Referencing
también podría tener el tarro añadido a su propio camino de construcción.
ADT 17 en adelante
Tratamiento de dependencias
Después de ADT 17 proyectos de la Library
que dinámicamente referenciado sus propios frascos comenzó a comportarse de manera extraña. No fue simplemente un caso de incluir la misma referencia dependiente en su proyecto de Referencing
para mantener el frasco visible en ambos ámbitos. Esto resultó en una extraña duplicación de las clases incluidas.
Desafortunadamente, simplemente la eliminación de la biblioteca del proyecto Referencing
o Library
(por lo que sólo un enlace estaba presente), entonces confundido eclipse, ya no podía ver el frasco del alcance del Proyecto que lo utilizaba.
Para arreglar esto, debes colocar los frascos de proyectos de la Library
en el directorio /libs
. Esto puede ser un dolor en la parte trasera si los frascos están en lugares dispersos en tu disco duro. Estos frascos se utilizarán automáticamente en los proyectos Library
y Referencing
.
Por lo tanto, para pasar pasado ADT 17:
- Elimine los archivos jar no utilizados como fuente en el ámbito de proyectos actual (ya sea éste su proyecto de
Library
oReferencing
). - Elimine los proyectos "biblioteca" de su proyecto de
Library
(en lugar de compilarlos en frascos). - Retire los frascos externos de su proyecto de
Library
, copiarlos en el directorio deLibrary
su lugar.
- ¿Por qué la verificación de firma en el servidor remoto es más segura que en el dispositivo?
- API11 (y ahora12) y Spannable causando NPE de tiempo de ejecución