Hemos investigado por diferentes espacios para así mostrarte la solución a tu duda, si tienes alguna inquietud puedes dejarnos tu pregunta y responderemos con mucho gusto, porque estamos para ayudarte.
Solución:
Me parece que las pruebas de instrumentación son pruebas de integración con la capacidad de controlar el ciclo de vida y los eventos (onStart, onCreate, etc.) de la aplicación.
Las pruebas unitarias, según lo entiendo, están probando una Unidad (por ejemplo, Clase) por sus datos y comportamiento.
Por ejemplo, supongamos que tiene un juego: este juego se ejecuta en una actividad (actividad principal) y tiene un personaje basado en una clase Robot, que tiene 2 métodos (disparar y moverse). Probaría la actividad principal con una prueba de instrumentación para ver si se guarda correctamente cuando sale de la aplicación, si se restaura correctamente cuando la restaura, etc. y probaría Robot con una prueba de unidad, para probar su attributes y comportamiento
Descargo de responsabilidad: No soy una persona de Java, pero me interesé en su pregunta y la respondí en base a una búsqueda menor en línea. Probablemente tengas que profundizar más en esto para encontrar una respuesta más detallada.
Pruebas unitarias aíslan el componente bajo prueba, y esta es la razón por la cual se suelen usar junto con Mocks frameworks como Mockito: porque aíslan la unidad de sus dependencias. Tenga en cuenta que lo que dice con respecto a la API de Android es parcialmente trueporque también existen pruebas unitarias instrumentadas, a saber La instrumentación también forma parte del paquete Junit, y también las clases que extienden TestCase ya que la clase AndroidTestCase es parte del paquete Junit pero permite el uso de A)Context, que puede llamar con getContext(), y B)Resources que son parte de la API de Android. Además, tenga en cuenta que AndroidTestCase es una clase base y que hay otras clases muy útiles que amplían esta clase. Prueban específicamente cargadores, proveedores de contenido e incluso servicios y también tienen acceso a la API de Android. por lo que estas clases proporcionan un marco de prueba JUnit, así como métodos específicos de Android. Ahora, con Junit4, existe ServiceTestRule que se extiende directamente desde Object y le permite probar un Servicio más fácilmente, aunque no puede iniciar un Intent directamente dentro de esta clase.
Pruebas de instrumentación también están en el paquete Junit, pero el control de la API de Android es bastante total porque las pruebas de instrumentación se instancian en el sistema antes de que se ejecute cualquier código de aplicación, y para probar necesita abrir la aplicación real (emulador o un teléfono conectado con USB). Acceden a los componentes de Android (p. ej., hacer clic en un botón) y al ciclo de vida de la aplicación. Por lo general, son más lentos que las pruebas de Junit que amplían TestCase (las examinadas anteriormente). El uso típico es con ActivityInstrumentationTestCase2 que tiene un enfoque de prueba funcional, más orientado al usuario.
EDITAR: Con respecto a Roboelectric y Mockito, que están junto con Espresso entre los marcos de prueba más populares en este momento (13 de julio de 2016), Roboelectric le permite ejecutar múltiples pruebas en segundos en lugar de minutos, y esto es muy útil en equipos que tienen que ejecutan pruebas continuas y están sujetos a integración continua.
Desde el sitio de Robolectric:
Un enfoque alternativo a Robolectric es usar marcos simulados como Mockito o simular el SDK de Android. Si bien este es un enfoque válido, a menudo produce pruebas que son esencialmente implementaciones inversas del código de la aplicación. Roboelectric permite un estilo de prueba más cercano a las pruebas 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 la implementación de Android. Todavía puede usar un marco de burla junto con Robolectric si lo desea.
Mockito que también se puede usar con Junit, se usa realmente con la excepción de cuando hay que manejar clases finales, clases anónimas o tipos primitivos.
EXAMEN DE LA UNIDAD
Pruebas unitarias que se ejecutan solo en su máquina local. Estas pruebas se compilan para ejecutarse localmente en la JVM para minimizar el tiempo de ejecución. Utilice este enfoque para ejecutar pruebas unitarias que no tengan dependencias en el marco de trabajo de Android o que tengan dependencias que los objetos simulados puedan satisfacer.
Básicamente, ejecuta código Java simple para probar, por ejemplo, un proveedor de contenido, conexiones de base de datos, entrada y salida de métodos. Esto no se ejecuta en Android. Para ejecutarlo NO necesitas un dispositivo.
PRUEBAS DE INSTRUMENTACIÓN
Pruebas unitarias que se ejecutan en un dispositivo Android o emulador. Estas pruebas tienen acceso a la información de Instrumentación, como el Contexto de la aplicación bajo prueba. Utilice este enfoque para ejecutar pruebas unitarias que tengan dependencias de Android que los objetos simulados no puedan satisfacer fácilmente.
Por lo tanto, se burla de cómo el usuario usará la aplicación real, por lo tanto, NECESITA un dispositivo (físico o emulador) para ejecutarlo. Tiene acceso a vistas, actividades, contexto, etc.
Referencia: http://developer.android.com/tools/testing/testing_android.html
Si sostienes alguna sospecha o disposición de desarrollar nuestro noticia eres capaz de ejecutar un exégesis y con mucho gusto lo observaremos.