¡La versión 2.0 de Play ya está lista! Ayúdanos a traducir la documentación de la útlima versión y sigue nuestro progreso.

Manuales, tutoriales & referencias

Consulte

Contenidos

Elija la versión

Buscar

Busque con google

Libros

Probando su aplicación

Una buena forma de hacer aplicaciones robustas es crear suites de pruebas automáticas, lo que le permite trabajar de una forma muy ágil y segura.

Las pruebas de Play se construyen usando JUnit 4 ó Selenium dependiendo de lo que se pretenda probar.

Creando pruebas

Las pruebas deben ser creadas en el directorio test/. Esta carpeta sólo se añadirá al path de fuentes cuando la aplicación se ejecute en modo test. Puede escribir tres clases de pruebas.

Pruebas unitarias

Se escriben usando JUnit. En esta clase de pruebas puede probar el modelo de la aplicación (incluyendo algunas utilidades).

Este es un ejemplo de una prueba unitaria:

import play.test.*;
import org.junit.*;
 
public class MyTest extends UnitTest {
     
    @Test
    public void aTest() {
        assertEquals(2, 1 + 1); // Una cosa que es realmente importante probar
    }
 
    @Test
    public void testUsers() {
        assertEquals(3, Users.count()); 
    }
}

Pruebas funcionales

También se usa JUnit. Mediante este tipo de pruebas puede probar la aplicación accediendo directamente a los objetos del controlador.

Este es un ejemplo de una prueba funcional:

import play.test.*;
import play.mvc.*;
import play.mvc.Http.*;
import org.junit.*;
 
public class ApplicationTest extends FunctionalTest {
     
    @Test
    public void testTheHomePage() {
        Response response = GET("/");
        assertStatus(200, response);
    }
     
}

Usando el método renderArgs(), también puede acceder a los argumentos que se pasen a la vista, en vez de tener que hacer assertions sobre la respuesta en sí misma. Por ejemplo:

@Test
public void testUserIsFoundAndPassedToView() {
    Response response = POST("/user/find?name=mark&dob=18011977")
    assertThat(renderArgs("user"), is(notNullValue());
    User user = (User) renderArgs("user");
    assertThat(user.name, is("mark"));
}

Pruebas Selenium o pruebas de aceptación

Las pruebas de aceptación se escriben usando Selenium. De esta manera podrá probar la aplicación ejecutándola directamente en un navegador web automatizado.

Las pruebas Selenium se escriben usando tablas HTML. Puede usarse esta sintaxis nativa o mediante el tag #{selenium /}.

Ejemplo de prueba Selenium:

#{selenium 'Test security'}
 
    // Intento de registrarse en el área de administración
    clearSession()
    open('/admin')
    assertTextPresent('Login')
    type('login', 'admin')
    type('password', 'secret')
    clickAndWait('signin')
 
    // Verificar que el usuario se ha registrado correctamente
    assertText('success', 'Welcome admin!')
 
#{/selenium}

Como las pruebas de Selenium se ejecutan dentro del navegador, hay que utilizar extensiones de Selenium para acceder a los mensajes enviados por el mail simulado (mock email) y a los valores de tipo String colocados en la Play Cache.

En el siguiente ejemplo, accedemos al último email enviado a una cuenta específica:

#{selenium 'Test email sending'}
 
    // Abrir formulario email y enviar un email a to boron@localhost
    open('/sendEmail')
    assertTextPresent('Email form')
    type('To', 'boron@localhost')
    type('Subject', 'Berillium Subject')
    clickAndWait('send')
 	
	// Extraer el último email enviado a boron@localhost en una variable
    // JavaScript llamada email
	storeLastReceivedEmailBy('boron@localhost', 'email')
	// Extraer el asunto de la variable email a una
    // variable llamada subject
	store('javascript{/Subject:\s+(.*)/.exec(storedVars["email"])[1]}', 'subject')
	// Probar el contenido de la variable subject
	assertEquals('Berillium Subject', '$[subject]')
 
#{/selenium}

En este ejemplo accedemos a un String guardado en la Cache de Play (por ejemplo, la respuesta correcta a un CAPTCHA):

#{selenium 'Get string from cache'}
 
	open('/register')
	assertTextPresent('Registration form')
	type('Email', 'my@email.com')
	type('Password', 'secretpass')
	type('Password2', 'secretpass')
	// .. Rellenar aqui el formulario de registro ...
 
	// Obtener el valor de la variable magicKey de la cache
	// (cargarlo en la respuesta al CAPTCHA de la aplicacion)
	storeCacheEntry('magicKey', 'captchaAnswer')
	// Escribirlo en el formulario
	type('Answer', '$[captchaAnswer]')
 
    clickAndWait('register')
 
#{/selenium}

Trabajando con Fixtures

Cuando se hacen pruebas, hay que tener datos bien conocidos para probar la aplicación. Lo más sencillo para esto es resetear la base de datos antes de cada prueba.

La clase play.test.Fixtures ayuda a manipular la base de datos y a inyectar datos de prueba. Se suele usar en el método @Before de una prueba JUnit.

@Before
public void setUp() {
    Fixtures.deleteAll();
}

Para importar los datos, los más sencillo es definirlos en un fichero YAML, de manera que el helper de Fixtures pueda importarlos automáticamente.

# Datos de prueba
 
Company(google):
   name:    Google
 
Company(zen):
   name:    Zenexity
 
User(guillaume):
   name:    guillaume
   company: zen

Y luego:

@Before
public void setUp() {
    Fixtures.deleteAll();
    Fixtures.loadModels("data.yml");
}

Puede leer más detalles acerca de Play y YAML en la página del manual de YAML.

En el caso de las pruebas Selenium puede usar el tag #{fixture /}

#{fixture delete:'all', load:'data.yml' /}
 
#{selenium}
    
    // Escribe aquí tu prueba
 
#{/selenium}

A veces es conveniente organizar los datos en varios ficheros YAML. Puede cargar los fixtures a partir de múltiples ficheros a la vez:

Fixtures.loadModels("users.yml", "roles.yml", "permissions.yml");

y para las pruebas Selenium:

#{fixture delete:'all', load:['users.yml', 'roles.yml', 'permissions.yml'] /}

Ejecutando las pruebas

Para ejecutar las pruebas, hay que correr la aplicación en modo test con el comando play test.

# play test myApp

Al ejecutarse en este modo, Play carga automáticamente el módulo test-runner. Este módulo contiene un ejecutador de pruebas Web, disponible en la URL: http://localhost:9000/@tests.

Cuando se ejecuta una prueba, el resultado se salva en el directorio /test-result de la aplicación.

En la página del ejecutador, cada prueba es un enlace. Puede hacer click con el botón derecho y seleccionar ‘Abrir en una nueva pestaña’ para ejeuctar directamente fuera del ejecutador.

Al ejecutar las pruebas de esta manera, Play arrancará framework ID especial llamado test. Así que puede definir configuraciones especiales en el fichero application.conf para ser usadas en modo test.

Si queremos tener diferentes configuraciones de pruebas, puede usar diversos frameworks ID que coincidan con el patrón test-?.* (p.ej.: test-special).

Si usamos un framework ID distinto de test, que es el ID por defecto, hay que asegurarse de que TODA la configuración de pruebas en application.conf esté disponible con ese framework ID. Para lanzar pruebas con un ID especial utilice el siguiente comando: play test --%test-your-special-id

Por ejemplo:

%test.db=mem
%test.jpa.ddl=create-drop

Integración continua y ejecución automática de pruebas

El comando auto-test hace lo mismo que el comando test, pero abre automáticamente un navegador, ejecuta todas las pruebas, y luego se detiene.

Es un comando muy útil cuando se quiere configurar un sistema de integración continua.

Tras la ejecución, se salvan todos los resultados en el directorio /test-result. Además, este directorio contiene un fichero (ya sea result.fail o bien result.passed) que contiene el resultado final. Por último, este directorio contiene todos los logs en el fichero application.log.

De modo que para configurar un sistema de integración continua para probar la aplicación, usted podría hacer lo siguiente:

  • Checkout de la última versión de la aplicación
  • Ejecutar play auto-test
  • Esperar a que el proceso finalice
  • Comprobar el fichero result.passed o result.failed en el directorio /test-result

Configurar una tarea CRON para ejecutar estos pasos y eso es todo.

Puede cambiarse el modo de compatiblidad del navegador para utilizar uno sin interfaz gráfica (lo que se conoce como headless browser) usando el parámetroheadlessBrowser.

Próximos pasos

Seguimos con Guía de Seguridad.