Prueba de unidad Android: ¿Cómo hacer que una clase sea más comprobable?

He estado desarrollando aplicaciones para Android, pero no he escrito ninguna prueba de unidad. Recientemente empecé a aprender sobre ello y tratar de usar JUnit para probar mis aplicaciones Android.

Descubrí que la mayoría de las veces tengo errores en las llamadas de API, pero todavía no puedo entender cómo escribir pruebas de unidad para ellos (y cómo hacer que el código original sea comprobable).

Permítanme explicar la siguiente función:

Estoy ejecutando una llamada de función setOffenceList (). Hay varias acciones que ocurren dentro de la función.

I) Cargue el RestClient y pase la URL.

Ii) RestClient habla con la API de JSON y obtiene la respuesta

Ii) Tomo la respuesta dentro de la función onSuccess (String response)

Iii) Analizar los datos JSON y almacenarlos dentro de una matriz

Iv) En caso de éxito, mostraré los datos en una vista de lista (si no se muestra un mensaje de error)

Este es el código:

public class OffenceFrag extends Fragment { @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { View view = inflater.inflate(R.layout.frag_offence, container, false); //run API call setOffenceList(); return view; } private void setOffenceList() { String url = Paths.SITE_URL ; RestClient.get(url, null, new AsyncHttpResponseHandler() { @Override public void onStart() { Toast.makeText(getActivity(), "Loading offences...", Toast.LENGTH_SHORT).show(); } @Override public void onSuccess(String response) { //Parse JSON JSONArray jsonArray; try { JSONObject jsonObj = new JSONObject(response); if(jsonObj.getString("status").equalsIgnoreCase("Success")){ jsonArray = new JSONArray(jsonObj.getString("data")); if(jsonArray.length() > 0){ for (int i = 0; i < jsonArray.length(); i++) { JSONObject row = jsonArray.getJSONObject(i); OffenceORM off = new OffenceORM(); off.setOffenceId(row.getString("offence_id")); off.setPhoto(row.getString("photo")); off.setSubmittedBy(row.getString("submitted_by")); offenceList.add(off); } } //Success: Show the list view setOffenceAdapter(); Toast.makeText(getActivity(), "Successfully Loaded", Toast.LENGTH_LONG).show(); } else { //Failed: show error message Toast.makeText(getActivity(), "There are no offences submitted under project", Toast.LENGTH_LONG).show(); } } catch (Exception e) { Log.e("exception", e.getMessage()); } } @Override public void onFailure(Throwable error, String content) { Log.e("failed", error.getMessage()); } @Override public void onFinish() { } }); } }//end 

Realmente no puedo entender cómo puedo escribir una función de prueba a algo como el código anterior.

¿Puede mostrarme cómo descomponer este código en piezas probables y escribir funciones de prueba de unidad en ellas?

¡Muchas gracias!

Solamente y sólo un buen diseño puede ayudarle a hacer la prueba de la Unidad más fácil. Es por eso que Test Driven Development está ahí. De modo que usted no puede ir con diseño incorrecto.

Cuando la unidad de prueba que simplemente prueba el código escrito por usted y utilizar objetos simulados proporcionados por Android para probar las llamadas de Api Android.

En cuanto a otros Api tienen problemas que su problema de desarrollador de Api no tuyo. Puede utilizar el marco de simulación como Mockito para probar la funcionalidad de su código cuando hace llamada a otro código de API. Pruebe el código del API por separado si está desarrollando su propia API.

Los principios de diseño deben ser seguidos para un buen diseño como

  • S – Principio de responsabilidad única
  • O – principio abierto-cerrado
  • L – Principio de sustitución de Liskov
  • I – Principio de segregación de interfaces
  • D – Principio de inversión de dependencia

Puntos importantes:

  • Una llamada de método de aserción por unidad de caso de prueba
  • No modifique las clases sólo para pruebas.
  • Uso de interfaces
  • No ponga demasiadas declaraciones o funcionalidad en un método.
  • No hagas clases muy grandes.
  • Utilice TDD ……. Muchos más

Prueba de unidad un código de diseño mal es desperdicio completo. Como la prueba se romperá cada vez que realice algunos cambios en las clases. En Android esto va a suceder aún más. Como usted está atascado con Android métodos de ciclo de vida.

Extraiga cuidadosamente la funcionalidad que desee probar en sus propias clases.

Esto hará que su código de aplicación sea más robusto, sencillo y claro.

Estás haciendo demasiadas cosas en Fragment, es difícil probar y dar mantenimiento.

Estoy utilizando el patrón MVP en mis proyectos, que permite separar la capa de presentación de la lógica, evitando poner todo el código en el fragmento / actividad.

Consulte este artículo: http://antonioleiva.com/mvp-android/

Y el ejemplo de código respectivo en GitHub: https://github.com/antoniolg/androidmvp

El consejo de Rohit Khatkar para utilizar TDD es sin duda vale la pena considerar para el siguiente código que desarrollar. Pero, ahora que este código existe y usted está preguntando "cómo dividir este código en piezas probables": Usted podría ignorar la testabilidad, y sólo tratar de dividir este código en partes más pequeñas: Exline definiciones de clases y dividir los métodos, Así como para optimizar la legibilidad en general. Usted ya encontrará alguna redundancia (el si alrededor del bucle for).

Como un efecto, cada uno de los métodos resultantes probablemente tendrá menos dependencias en otras clases. A continuación, puede centrarse en la reducción de estas dependencias. Echa un vistazo al libro de Michael Feather sobre cómo tratar el código heredado para un montón de enfoques para romper las dependencias. EDIT: Alguien ha extraído una lista de técnicas de ruptura de dependencia (sólo descripciones de alto nivel, sin embargo): http://rubyexperiences.blogspot.de/2005/12/dependency-breaking-techniques-from.html

  • ¿Cómo ejecutar una prueba JUnit4 simple en Android Studio 1.1?
  • Ejecute una sola prueba de Android (unidad) desde gradle sin cargar otras dependencias de proyecto
  • Instrumentation.ActivityMonitor no monitoreando Intent.ACTION_CALL
  • ¿Cómo volver a ejecutar la prueba fallada en Espresso? - lluvia de ideas
  • ¿Por qué AndroidTestCase.getContext (). GetApplicationContext () devuelve null?
  • Prueba de la unidad de Android que no informa Fallando con error ()
  • Módulo de prueba de inyección con dagger2
  • Fragmento getActivity () devuelve null en la actividad JUnit test
  • Proyecto de biblioteca de prueba autónoma no puede encontrar las clases de biblioteca
  • Error en el corredor al realizar pruebas con Robolectric
  • ¿Intentar ejecutar Android JUnit pruebas en Eclipse falla?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.