Header Ads Widget

Ticker

6/recent/ticker-posts

La propiedad de prueba temporal

El hecho de que pueda convertir una variable en una propiedad a largo plazo de un dispositivo de prueba no significa que deba hacerlo.

Este es el olor de prueba de Todo es una propiedad .

Se puede ver en lenguajes como JavaScript, donde hay un maestro que letconfigura algunas variables útiles para que varias pruebas usen para asignar valores. Sin embargo, lo he visto más en Java, donde puede haber una especie de fobia a crear variables temporales dentro de las pruebas, por lo que, en cambio, todas las variables se declaran en la clase principal.

Veamos un ejemplo rápido:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
dieciséis
17
18
19
20
21
22
23
24
25
class ParagraphAnalyzerTest {
    private String analyzed;
    private ParagraphAnalyzer analyzer = new ParagraphAnalyzer();
 
    @Test
    void nouns() {
        analyzed = analyzer.justNouns("This is a word");
        assertThat(analyzed).isEqualTo("word");
    }
 
    @Test
    void verbs() {
        analyzed = analyzer.justVerbs("This is a word");
        assertThat(analyzed).isEqualTo("is");
    }
 
    @Test
    void ends() {
        analyzed = analyzer.first("This is a word");
        assertThat(analyzed).isEqualTo("This");
 
        analyzed = analyzer.last("This is a word");
        assertThat(analyzed).isEqualTo("words");
    }
}

En el ejemplo ficticio simple anterior, la clase de prueba tiene dos miembros. Hay ParagraphAnalyzercuál es el código que se está probando y cuál parece tener sentido tener como miembro del dispositivo. Luego está lo analyzedque parece tener un valor diferente en cada prueba.

El hecho de que cada prueba dé su propio valor al analyzedes un olor que analyzedno está siendo manejado por el dispositivo de prueba y, por lo tanto, no pertenece como una propiedad del mismo.

Estamos guardando una declaración repetida de Stringcada vez ... que no vale la pena el equipaje de esta propiedad compartida riesgosa.

Ahora, el riesgo probablemente no sea nada, porque la prueba anterior creará una nueva instancia de la clase para cada caso de prueba, por lo que no hay sangrado entre los estados ... pero eso solo es cierto si no cambio el ciclo de vida de la instancia de prueba. JUnit 5 me permitirá hacer esto de manera diferente. Además, si tengo la costumbre de usar miembros para variables temporales, ¿qué me impide hacer eso también con los staticmiembros?

No hay justificación para que esta variable temporal se promueva en algún lugar más alto de la cadena alimentaria.

También puede notar otro antipatrón de prueba en la última prueba unitaria, arriba. El valor de analyzedse está reasignando. Otro movimiento incómodo. Este es el olor de prueba Dos por el precio de uno , donde un solo caso de prueba ejecuta dos casos de uso independientes.

¿Cuándo usar qué?

Considere que cada caso de prueba tiene su propio estado. El caso de prueba hereda cualquier estado comúnmente configurado o derribado del dispositivo de prueba. Este enfoque evita la repetición de código y otras dificultades con la configuración de recursos costosos para cada prueba.

Pero ... tan pronto como se realiza la configuración común, cada caso de prueba debe hacer lo suyo, claramente y sin ensuciar el dispositivo de prueba con sus problemas.

Almacenar lo que es esencialmente el alcance de la solicitud en el estado de instancia de un objeto es un patrón anti fuera de las pruebas y también debe considerarse dentro de él.

Publicar un comentario

0 Comentarios