Mi compañero y yo vamos a tener un tiempo difícil entender si la prueba de mutación puede / debe hacerse sobre JUnit pruebas refiriéndose a Swing clases.
De manera más precisa, está usando actualmente Junit 4 y Assertj El columpio para probar la interfaz para una misión en la prueba (con TDD) en la universidad. También estamos utilizando PITEST como marco de pruebas de mutación.
Hemos incorporado las clases Swing con WindowBuilder plug-in para Eclipse, y como tal no tiene mucho control sobre cómo se estructuran las clases. Las pruebas unitarias son de color verde, pero cuando se ejecuta en boxes una tonelada de excepciones son lanzadas por hoyo en estas clases y las pruebas fallan miserablemente. Se puede ver el registro de maven de Travis .
Dado que estamos empezando a entender el mundo de pruebas, una sugerencia de alguien que realmente se ocupa de estas cosas sería muy apreciada.
Muchas gracias.
Mutación pruebas se utilizan para probar su cobertura de la prueba, no el código. Así que cuando fallan las pruebas que está bien y su cobertura de prueba es aceptable.
El problema es que las pruebas de interfaz de usuario son difíciles de código y que no son muy estables (al menos por lo que era hace unos años, especialmente para Linux). Así que la mutación pruebas proporcionan ningún valor adicional para ellos. Cualquier pequeño cambio en el código de interfaz de usuario puede proporcionar un seguimiento de pila no explicable, por lo que no se puede decir si las pruebas son buenas o swing es demasiado complejo y pueden ser facilmente conseguir abajo (oscilación lanza toneladas de excepciones, por lo que cualquier pequeño cambio puede provocar una de ellos).
Mi sugerencia es estándar: separar el código de interfaz de usuario de la lógica de negocio y proporcionar pruebas normales para sus clases de negocios. En este caso las pruebas de mutación puede ser razonable.