tesis - Burlarse de la biblioteca/marco que funciona mejor en Android?
tesis sobre youtube pdf (7)
Acabo de probar Android-Mock. Funciona muy bien hasta ahora. Resolvió mi problema (use AndroidTestCase sin EasyMock o use EasyMock pero no se permite el contexto)
Estoy desarrollando aplicaciones de Android usando bibliotecas de terceros (Twitter4j). Quiero poder simular esos objetos (también objetos creados por mí) en JUnit y pruebas funcionales.
¿Tienes alguna buena experiencia al usar algunas bibliotecas de burlas y puedes recomendarlas?
Lmock está trabajando en Android: github.com/vmware/lmock
Recientemente lancé Borachio, un framework de burla nativo de Scala que funciona en Android.
Debido a que Borachio está escrito en Scala, deberás escribir tus pruebas en Scala. Pero se puede usar para probar código escrito en Java.
Hay una descripción de cómo usar Borachio en Android en mi blog:
http://www.paulbutcher.com/2011/03/mock-objects-on-android-with-borachio-part-1/ http://www.paulbutcher.com/2011/03/mock-objects-on- android-with-borachio-part-2 / http://www.paulbutcher.com/2011/03/mock-objects-on-android-with-borachio-part-3/
ACTUALIZAR:
Borachio ahora es ScalaMock .
android-mock está escrito en la parte superior de EasyMock que es un marco falso famoso para Java
pivotal.github.com/robolectric usa un enfoque diferente. En lugar de ejecutar en el DVM, "defangs" del SDK de Android para que pueda ejecutar pruebas de Android directamente en la JVM con el marco JUnit4. Las pruebas aparentemente se desarrollan y corren mucho más rápido, y requieren menos burlas.
[Un enfoque común] es utilizar marcos simulados como Mockito o Android Mock para burlarse del SDK de Android. Si bien este es un enfoque válido, hemos descubierto que sin Robolectric, el nivel de burla necesario para probar una aplicación de Android produce rápidamente pruebas que son esencialmente implementaciones inversas del código de la aplicación.
Robolectric permite un estilo de prueba más cercano a la prueba de caja negra, lo que hace que las pruebas sean más efectivas para la refactorización y permite que las pruebas se centren en el comportamiento de la aplicación en lugar de en la implementación de Android. Todavía puede utilizar un marco de burla junto con Robolectric si lo desea.
Así es como funciona:
[Se intercepta] la carga de las clases de Android y la reescritura de los cuerpos del método. Robolectric redefine los métodos de Android para que devuelvan nulo (o 0, falso, etc.) o, si se proporcionan, Robolectric reenviará llamadas a métodos para sombrear objetos de Android, lo que dará como resultado el comportamiento del SDK de Android.
(Actualización: Mockito ha agregado compatibilidad con Android a partir de la versión 1.9.5 y EasyMock ha agregado compatibilidad con Android a partir de la versión 3.2 al descomponer los bits que generan código en tiempo de ejecución y hacerlos conectables, por ejemplo, usando dexmaker en lugar de cglib).
A excepción de android-mock mencionado por DixonD (que es una biblioteca bastante joven, no probada), actualmente no hay solución. Puede olvidarse de inmediato cualquier cosa basada en CGLib ( Mockito , Mockito simple), ya que CGLib depende de la generación de código byte y no funcionará en Dalvik (también depende del paquete de Java Beans, que tampoco es parte de Android).
Por si sirve de algo, podrías usar las pocas clases simuladas que vienen con Android (como MockContext ), pero no verifican el comportamiento, solo son talones. Su comportamiento predeterminado es arrojar un error de tiempo de ejecución en cada método, por lo que debe subclasificarlos y anular los métodos que desea simular.
Sin embargo, aún puede usar libretas de burlas en pruebas que no son de instrumentación, es decir, en las pruebas de unidad estándar ejecutadas en la JVM. Puede usar PowerMock para PowerMock métodos de framework, tiene soporte para burlarse de métodos estáticos y constructores, haciendo que el burlarse sea tan poderoso como, por ejemplo, en Ruby (simplemente es más doloroso de usar).
Usamos JUnit 4 + PowerMock + Mockito y simulamos clases como Context y TextUtils en una clase base de la cual heredamos cada prueba JUnit normal. Para las pruebas de instrumentación, creamos clases simuladas personalizadas y decidimos utilizar una fábrica cuya implementación (simulada o no) creará instancias en el tiempo de ejecución.
actualización: parece que easymock 3.2 agregó una opción para conectar alternativas para cglib.
Estoy usando easymock 2.5.2 (nota - no use 3.X). funciona, pero solo para interfaces de burla .
Por lo tanto, si su biblioteca expone interfaces o si está dispuesto a envolver nuestras dependencias con interfaces, puede usar easymock.
Las versiones posteriores de easymock como easymock 3.x no funcionarán porque usan el cglib android-incompatible para la manipulación de bytecode para ambas clases e interfaces, mientras que 2.x lo usa solo para clases de burla.