Para tener una cierta confianza en que la aplicación resuelve un cierto problema se llevan a cabo pruebas funcionales; estas resuelven un ejemplo concreto y representativo simulando las acciones del usuario y verificando que la reacción de la aplicación es la esperada.

Las pruebas funcionales han de mantenerse al día y evolucionar con los cambios de la aplicación y sus requisitos. Otro de los retos es que sean correctas, es decir, que el comportamiento que estén verificando sea realmente el que se requiere de la aplicación.

Es crucial que las pruebas funcionales estén automatizadas; lo típico es escribirlas en el mismo lenguaje de programación de la aplicación. Esto nos permite ejecutar un gran número de ellas de forma sistemática y tras cada cambio, con lo que también nos protegerán de que algo que funcionaba deje de hacerlo, es decir, de posibles regresiones.

public class ListStaysEmptyTest {
    private WebDriver webDriver;
    private NeverReadServer neverread;

    @Test
    public void articleListStaysEmptyWhenAddingNewArticle() {
        webDriver.findElement(By.name("url")).sendKeys("interesting/article.html", Keys.ENTER);
        assertThat(webDriver.findElements(By.cssSelector("li")).size(), is(0));
    }

    @Before
    public void setUp() throws Exception {
        neverread = new NeverReadServer();
        neverread.start(8081);

        WebDriver driver = new HtmlUnitDriver();
        driver.get("http://localhost:8081");
        webDriver = driver;
    }

    @After
    public void tearDown() throws Exception {
        webDriver.close();
        neverread.stop();
    }
}

Si bien podríamos considerar que nuestra prueba funcional en Java es la documentación principal donde se registran los criterios de aceptación; dependiendo de quién vaya a consumirla, esto puede o no ser una opción. Además, conseguir reemplazar la legibilidad de un párrafo en español con una prueba en el lenguaje de programación es todo un reto, particularmente si el lenguaje de programación es tan prolijo como Java.

En consecuencia, en la mayoría de los proyectos es necesario documentar los requisitos de manera más textual.

Una forma de intentar obtener lo mejor de las dos alternativas es conectar la documentación a la aplicación de tal forma que en todo momento sea automático y evidente verificar el cumplimiento de cada uno de los requisitos expresados, lo que nos ayudará a mantener la documentación sincronizada con la aplicación y con el cliente.

La documentación, junto con la capacidad de procesarla para su verificación, servirá así de batería de pruebas funcionales; si ejecutamos esta batería con frecuencia (idealmente con cada cambio) y la mantenemos veraz, estaremos garantizando el correcto funcionamiento de la aplicación… para la definición especificada.

Concordion es una de las herramientas que nos pueden ayudar a conectar la documentación con la aplicación; en Concordion los criterios se escriben en HTML al que se añaden algunas marcas que comienzan con concordion:

<p>
  When an article is added, the list of unread articles stays empty
</p>

<div class="example">
<h3>Example</h3>

<p>
  When the article
  <b concordion:set="#url">interesting/article.html</b>
  is added, the list of unread articles stays
  <b concordion:assertEquals="articleListAfterAdding(#url)">empty</b>
</p>
</div>

Primera prueba usando Concordion (concordion/v1/ListStaysEmpty.html)

Vemos que hemos expresado el ejemplo en forma de condición y consecuencia que se debe verificar. Los atributos concordion:set y concordion:assertEquals conectan el documento al método de la clase de respaldo, escrita en Java, String articleListAfterAdding(String url), que se encargará de hacer lo que dice el texto.

public class ListStaysEmptyTest extends ConcordionTestCase {
    private WebDriver webDriver;
    private NeverReadServer neverread;

    @SuppressWarnings(value = "unused")
    public String articleListAfterAdding(String url) throws InterruptedException {
        webDriver.findElement(By.name("url")).sendKeys(url, Keys.ENTER);
        List<WebElement> pendingArticles = webDriver.findElements(By.cssSelector("li"));

        return convertListOfArticlesToString(pendingArticles);
    }

    private static String convertListOfArticlesToString(List<WebElement> pendingArticles) {
        if (pendingArticles.isEmpty()) return "empty";
        else {
            StringBuilder stringBuilder = new StringBuilder();
            stringBuilder.append(pendingArticles.get(0).getText());

            for (int i = 1; i < pendingArticles.size(); i++)
                stringBuilder.append(", ").append(pendingArticles.get(i).getText());

            return stringBuilder.toString();
        }
    }

Clase de respaldo de la prueba en Concordion (purejava/ListStaysEmptyTest.java)

Al ejecutar ListaPermaneceVaciaTest, Concordion generará un documento HTML con el texto anterior en el que se indicará si se cumple la aserción resaltándola en verde o rojo.

public String articleListAfterAdding(String article) throws InterruptedException {
    driver.addArticle(article);
    return convertListOfArticlesToString(driver.getListOfArticles());
}

public String articleListAfterAdding(String url) throws InterruptedException {
    page.enterIntoNewArticlesTextBox(url);
    List<String> pendingArticles = page.getArticlesInListOfArticles();

    return convertListOfArticlesToString(pendingArticles);
}

En las secciones anteriores nos hemos permitido hacer un poco trampas que deberíamos descubrir antes de cerrar el artículo. Supongamos que el desarrollador, al escribir el código de la aplicación comete una equivocación por no entender debidamente lo que necesita el cliente; decide hacer una aplicación que añade los artículos a una lista de artículos a leer. Nuestras pruebas funcionales deberían detectar este error marcando la aserción en rojo. Sin embargo, nos encontramos con que la pruebas pasan.

Evidentemente, nuestras pruebas funcionales no son correctas, esto se debe a que estamos verificando que el estado de la lista de artículos es el mismo después de entrar el nuevo artículo que antes de entrarlo, y la prueba verifica la condición antes de que la aplicación tenga tiempo de añadir erróneamente artículos a la lista.

Probar sistemas asíncronos es lo suficientemente complejo como para justificar un artículo en sí mismo, pero si enumeramos algunas de las opciones, de más rápidas y sencillas de implementar a menos, tenemos:

En nuestro ejemplo sabemos que, cada vez que la aplicación responde a la entrada de un nuevo artículo, lo último que hace es borrar la caja de texto. Por lo tanto, podemos utilizar este evento como punto de sincronización, es decir, antes de verificar que la lista permanece vacía esperaremos a que la caja se haya borrado.

public void addArticle(String url) {
    webDriver.findElement(By.name("url")).sendKeys(url, Keys.ENTER);

    new WebDriverWait(webDriver, 2).until(new ExpectedCondition<Object>() {
        @Override
        public Object apply(WebDriver webDriver) {
            return "".equals(webDriver.findElement(By.name("url")).getAttribute("value"));
        }
    });
}

public List<String> getListOfArticles() {
    return webElementsToTheirTexts(webDriver.findElements(By.cssSelector("li")));
}

Ejemplo de punto de sincronización (concordion/v5_with_synchronisation/tools/NeverReadDriver.java)

La documentación activa es una forma de probar funcionalmente un programa en el que cada criterio de aceptación se enuncia con un texto que se enlaza a la ejecución de código que verifica el criterio. Al ejecutarla, se produce un resultado que indica, de forma legible para los expertos del dominio, qué criterios de aceptación cumple el programa y qué criterios no cumple. Como casi todo, su uso debería adaptarse a la composición del equipo y la complejidad del proyecto.