Tengo un problema al ejecutar las pruebas de la unidad de android contra las aplicaciones de Android que utilizan la API de compatibilidad de Fragment recientemente lanzada. Cuando la prueba se ejecuta contra una FragmentActivity, el siguiente error aparece en el registro y la clase no se carga. Cuando se ejecuta contra una clase idéntica, pero una derivada de la actividad, la prueba funciona bien. ¡Ambas clases funcionan correctamente como aplicaciones! Lo que significa que cuando se invoca simplemente ambos muestran su diseño y función correctamente. El contenedor de soporte es parte de la ruta de compilación e incluido en el proyecto.FragmentActivity no se puede probar a través de ActivityInstrumentationTestCase2
El problema que tengo es que la única forma de utilizar fragmentos (y es compatible con Android pre3.0) es utilizar FragmentActivity, pero si eso excluye las pruebas automatizadas, ¿de qué sirve esta biblioteca?
4-05 18:00:11.276: WARN/dalvikvm(1095): Class resolved by unexpected DEX: Lcom/example/android/app/FragmentLayoutSupport;(0x406351a0):0x12e5c8 ref [Landroid/support/v4/app/FragmentActivity;] Landroid/support/v4/app/FragmentActivity;(0x406351a0):0x12e440
04-05 18:00:11.276: WARN/dalvikvm(1095): (Lcom/example/android/app/FragmentLayoutSupport; had used a different Landroid/support/v4/app/FragmentActivity; during pre-verification)
04-05 18:00:11.286: WARN/dalvikvm(1095): Unable to resolve superclass of Lcom/example/android/app/FragmentLayoutSupport; (49)
04-05 18:00:11.286: WARN/dalvikvm(1095): Link of class 'Lcom/example/android/app/FragmentLayoutSupport;' failed
04-05 18:00:11.286: ERROR/dalvikvm(1095): Could not find class 'com.example.android.app.FragmentLayoutSupport', referenced from method com.example.android.app.test.FrameLayoutTest.<init>
04-05 18:00:11.286: WARN/dalvikvm(1095): VFY: unable to resolve const-class 131 (Lcom/example/android/app/FragmentLayoutSupport;) in Lcom/example/android/app/test/FrameLayoutTest;
Aquí está el código que construí para demostrar el problema. El caso de prueba, simplemente intenta crear una instancia de la clase bajo prueba:
FrameLayoutTest.java
public class FrameLayoutTest extends
ActivityInstrumentationTestCase2<FragmentLayoutSupport> {
public FrameLayoutTest() {
super(FragmentLayoutSupport.class);
}
public void testActivityTestCaseSetUpProperly() {
assertNotNull("activity should be launched successfully", getActivity());
}
}
Las dos clases que he creado son los siguientes y fragment_layout es un LinearLayout vacío:
FrameLayout.java
public class FragmentLayout extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.fragment_layout);
}
}
Y
FragmentLayoutSupport.java
public class FragmentLayoutSupport extends FragmentActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.fragment_layout);
}
}
Eso era exactamente la misma. Vi esa línea en el registro de depuración, pero me sorprendió. Pensé que estaba diciendo que había usado diferentes versiones de android-support-v4.jar, que no tenía. Supongo que lo que está sucediendo es que la compilación de cada proyecto con su propia vinculación de ese archivo jar dio como resultado dos archivos dex codificados de forma exclusiva. Muy complicado y agradable de haber resuelto. Estaba casi listo para abandonar fragmentos como estaban, para todos los propósitos prácticos, no comprobables si usabas el lib de soporte. – securelpb
Eres un salvavidas, esto me ha estado golpeando durante unas buenas tres horas. – tomtheguvnor
¿Por qué no se aceptó como respuesta correcta? – Bostone