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).
- Android JUnit4 Pruebas - ¿Dónde obtener el contexto de?
- Junit / Mockito - esperar la ejecución del método
- Android Marshmallow Permisos de Pruebas
- Mono Android. Marco de pruebas unitarias
- Akquinet (Android con el arquetipo de prueba) - las pruebas de unidad no se ejecutan
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!
- Java.lang.IllegalAccessError: Clase ref en clase pre-verificada resuelto a la implementación inesperada obteniendo mientras ejecuta proyecto de prueba?
- La compatibilidad con la prueba de unidades Android no funciona en los módulos de la biblioteca de Android
- Cómo burlar getApplicationContext
- Unidad de prueba SparseArray utilizando JUnit (utilizando JVM)
- JUnit en android
- La prueba de Android JUnit de Simpe se cuelga en Eclipse
- ¿Puedo probar las notificaciones de la barra de estado utilizando el marco de pruebas de Android?
- ¿Cómo ejecutar pruebas de unidad para Android no está en el dispositivo o emulador?
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
- Utilizar un solo diseño xml para múltiples actividades con diferentes datos
- Cómo agregar funcionalidad WebRTC en la aplicación de Android