2011-02-06 31 views
19

Existen varios métodos de pruebas unitarias en Android, ¿cuál es el mejor para probar una vista personalizada que he escrito?Android: ¿Cómo probar una vista personalizada?

Actualmente estoy probándolo como parte de mi actividad en un caso de prueba de instrumentación, pero preferiría probar solo la vista, aislado.

+0

¿Qué quiere decir por 'probar la vista'? – pkananen

Respuesta

18

La prueba de unidades de pozo es un método mediante el cual se prueban unidades individuales de código fuente para determinar si son aptos para su uso. Entonces, cuando dice que quiere probar su vista personalizada, puede verificar varios métodos de sus vistas personalizadas como "onTouchEvent", "onDown", "onFling", "onLongPress", "onScroll", "onShowPress", "onSingleTapUp", "onDraw" y varios otros dependiendo de su lógica comercial. Puede proporcionar valores simulados y probarlo. Sugeriría dos métodos para probar tu vista personalizada.

1) Monkey Testing La prueba de mono es una prueba aleatoria realizada por herramientas de prueba automatizadas. Una prueba de mono es una prueba unitaria que se ejecuta sin una prueba específica en mente. El mono en este caso es el productor de cualquier entrada. Por ejemplo, una prueba mono puede ingresar cadenas aleatorias en cuadros de texto para asegurar el manejo de todas las posibles entradas de los usuarios o proporcionar archivos basura para verificar las rutinas de carga que tienen fe ciega en sus datos. Esta es una técnica de prueba de caja negra y puede verificar su vista personalizada en tantas condiciones únicas que se sorprenderá :).

2) Unidad de Pruebas

2a) Uso Robotium Unidad de Pruebas Framwork

Ir a Robotium.org o http://code.google.com/p/robotium/ y descargar el proyecto ejemplo de ensayo. Robotium es un framework realmente fácil de usar que hace que las pruebas de las aplicaciones de Android sean fáciles y rápidas. Lo creé para hacer posible las pruebas de aplicaciones avanzadas de Android con el mínimo esfuerzo. Se usa junto con ActivityInstrumentationTestCase2.

2b) Marco Prueba Uso Android

Éstos son los vínculos con la referencia: http://developer.android.com/reference/android/test/ActivityInstrumentationTestCase2.html y http://developer.android.com/reference/android/test/ActivityUnitTestCase.html

Para empezar: http://developer.android.com/guide/topics/testing/testing_android.html

De acuerdo a un usuario: Aparte de probar fácilmente la plataforma no Depende de la lógica No he encontrado un manera inteligente de ejecutar pruebas, hasta ahora (en menos para mí) cualquier plataforma real pruebas lógicas es engorroso. Es casi no trivial de todos modos porque he diferencias encontradas en la aplicación entre el emulador y mi real dispositivo y no me gusta para ejecutar una unidad de prueba aplicación en el dispositivo sólo para eliminar la aplicación después.

Mi estrategia ha sido: Trata de ser concisa y hacer el bien lógica pensado y luego probar pieza a pieza aplicación (menos entonces deseable).

también Stephen Ng proporciona un buen aproach para la prueba real de la unidad para la solución de proyectos de Android: https://sites.google.com/site/androiddevtesting/

Un usuario ha hecho un screencast.

Aquí hay un ScreenCast que hice sobre cómo hice que las Pruebas unitarias funcionaran. Unidad simple Las pruebas y las pruebas unitarias más complejas que dependen de tener una referencia a Objetos de contexto o actividad. http://www.gubatron.com/blog/2010/05/02/how-to-do-unit-testing-on-android-with-eclipse/

espero que le ayuda a probar la vista personalizada en todas las condiciones posibles :)


Comentarios (futlib) Todas sus sugerencias parecen implicar ensayar la actividad, mientras que lo que realmente quiero prueba solo la VISTA. Es posible que desee utilizar esta vista en otras actividades, por lo que no tiene mucho sentido que la pruebe con una específica. - futlib

Respuesta: Para aplicar una vista personalizada, lo normal es empezar por proporcionar anulaciones para algunos de los métodos estándar que el marco pide a todas las vistas. Por ejemplo "onDraw", "onKeyDown (int, KeyEvent)", "onKeyUp (int, KeyEvent)", "onTrackballEvent (MotionEvent)" etc. de su vista personalizada. Entonces, cuando desee hacer pruebas de unidades para su medida personalizada, tendrá que probar estos métodos, y le proporcionará valores simulados para que pueda probar su vista personalizada en todos los casos posibles . Probar estos métodos no significa que esté probando su ACTIVIDAD , pero significa probar su vista personalizada (métodos/funciones) que se encuentra dentro de una actividad. También tendrá que poner su vista personalizada en una actividad eventualmente para que los usuarios de su objetivo lo experimenten. Una vez probado , su vista personalizada se puede colocar en muchos proyectos y muchas actividades.

+1

Todas sus sugerencias parecen implicar probar la ACTIVIDAD, mientras que realmente quiero probar solo la VISTA. Es posible que desee utilizar esta vista en otras actividades, por lo que no tiene mucho sentido que la pruebe con una específica. – futlib

+0

@futlib, he editado mi respuesta y la he explicado con más detalle. Por favor, míralo. –

+0

Eso aclara las cosas, pero mi pregunta central es: ¿Qué tipo de método de prueba puedo usar para eso? Pruebas de instrumentación? Aquellos necesitan una Actividad. ¿O pruebas simples de JUnit? ¿O AndroidTestCase o ApplicationTestCase? – futlib

20

Una solución simple para la falta de una implementación de TestCase orientada a la vista sería crear una actividad simple dentro de su proyecto de prueba que incluya su vista. Esto le permitirá escribir pruebas contra la vista usando una Actividad simple. Información sobre las pruebas de la actividad:

http://developer.android.com/reference/android/test/ActivityUnitTestCase.html

+0

Entonces, ¿eso significa que tendré que crear una actividad "simulada"? Bueno, es suficiente. – futlib

+0

+1 para la versión concisa de la respuesta. – cdhabecker

13

He aquí una sugerencia diferente, que funciona bien en muchos casos: Suponiendo que se hace referencia a la vista personalizada desde un archivo de diseño, puede utilizar un AndroidTestCase, infle la vista, y luego realizar pruebas en contra de manera aislada. Aquí hay un código de ejemplo:

my_custom_layout.xml:

<?xml version="1.0" encoding="utf-8"?> 
<de.mypackage.MyCustomView ... 

MyCustomView.java:

public class MyCustomView extends LinearLayout { 

    public MyCustomView(Context context, AttributeSet attrs) { 
     super(context, attrs); 
    } 

    public void setTitle(CharSequence title) { 
     ((TextView) findViewById(R.id.mylayout_title_textView)).setText(title); 
    } 
... 

MyCustomViewTest.java:

public class MyCustomViewTest extends AndroidTestCase { 

    private MyCustomView customView; 

    @SuppressLint("InflateParams") 
    @Override 
    protected void setUp() throws Exception { 
     super.setUp(); 
     customView = (MyCustomView) LayoutInflater.from(getContext()) 
      .inflate(R.layout.my_custom_layout, null); 
    } 

    public void testSetTitle_SomeValue_TextViewHasValue() { 
     customView.setTitle("Some value"); 
     TextView titleTextView = (TextView) valueSelection.findViewById(R.id.mylayout_title_textView); 
     assertEquals("Some value", titleTextView.getText().toString()); 
    } 
... 
+0

¿Qué es 'valueSelection' en' TextView titleTextView = (TextView) valueSelection.findViewById (R.id.mylayout_title_textView); '? – beerBear

+0

No estoy seguro, para ser sincero (hace mucho tiempo), pero creo que es un error tipográfico, probablemente debería ser 'customView' (que contiene ese' TextView'). – csoltenborn

Cuestiones relacionadas