Testng: @Test (habilitado = falso) anotación a nivel de clase debe deshabilitar todos los métodos en la clase

Hola Nicolas,

Debería ver esto si no usa ningún método @Test en sus métodos, pero tan pronto como lo haga (como lo hace en su ejemplo anterior con dataProvider), el atributo enabled se anula y es predeterminado. es cierto, de ahí el comportamiento que está viendo.

¿Esto tiene sentido?

Sí, gracias Cedric.

Hago la suposición incorrecta de que la anotación @test (habilitado = falso) en la clase excluye por completo la clase de la ejecución

Estoy de acuerdo en que es un poco contrario a la intuición, pero es demasiado tarde para cambiar ahora, lamentablemente ...

¡Hola, Cedric!
¿Qué hay de agregar un nuevo parámetro a la anotación @Test y llamarlo algo como "enabledClass" y hacerlo verdadero de forma predeterminada? Debe usarse solo a nivel de clase (enabledClass = false) para deshabilitar toda la clase independientemente de las anotaciones a nivel de método y debe ignorarse, si se agrega para el método.
De esta manera, mantendríamos la compatibilidad con versiones anteriores y proporcionaríamos una funcionalidad bastante útil al mismo tiempo.
Si lo desea, puedo implementarlo yo mismo y proporcionar una solicitud de extracción.
¡Gracias por adelantado!

@ andronix83 ,

Me temo que esto hace las cosas más confusas ahora que necesita explicar la sutil diferencia entre enabled y enabledClass .

El comportamiento actual de enabled no es el más intuitivo, pero no parece ser un problema en general, a juzgar por la cantidad de veces que se ha planteado este problema (casi nunca).

Hola Cédric,

De hecho, me encontré con este problema la semana pasada. Estoy trabajando en un servidor web que se basa en la API Graph de Facebook. Tuve una clase de prueba que tenía algunos métodos de prueba que se basaban en el código que golpeaba la API Graph, y otros métodos de prueba no necesitaban depender en absoluto de ese servicio. Luego, hubo una interrupción global en Facebook en su conjunto durante más de una hora. Esto dio como resultado que algunas de las pruebas de esta clase fallaran.

Lo que esperaba hacer, para mantener al resto de mi equipo de desarrollo desbloqueado, es simplemente deshabilitar todas las pruebas en esta clase inmediatamente, a través de una anotación @Test (habilitado = falso) en el nivel de la clase. Por supuesto, eso no funcionó. En cambio, tuve que deshabilitar cada método de prueba fallido uno por uno, lo que me llevó más tiempo del deseado, o incluso necesario, para resolver este problema.

Idealmente, TestNG admite algún tipo de funcionalidad similar a la anotación @Ignore de JUnit: http://junit.sourceforge.net/javadoc/org/junit/Ignore.html. En pocas palabras, los desarrolladores están deseando esta funcionalidad.

Gracias.

@ecbrodie Esto ya es compatible (¡pruébalo!) pero hay una advertencia: cada método individual que tenga una anotación @Test volverá a habilitar la prueba.

@Test(enabled = false)
public class T {
  void f() {} // will not run
}

@Test(enabled = false)
public class T {
  <strong i="10">@Test</strong>
  void f() {} // WILL run!
}

Esto se debe a la semántica que los atributos en el nivel de método anulan los atributos definidos en el nivel de clase, por lo que la anotación de nivel de método @Test básicamente dice @Test(enabled = true) ya que es el valor predeterminado ...

¿Tiene sentido?

Hola @cbeust , gracias por ese ejemplo, pero ese ya era el entendimiento del problema, así que creo que es posible que me hayas entendido mal. Ese punto que estaba tratando de hacer fue, dada la semántica actual de @Test (habilitado = verdadero / falso) y el deseo de tener una forma de especificar una anulación de habilitado en el nivel de clase para ignorar lo que esté configurado en el método nivel, tal vez sea hora de reconsiderar su postura en contra de agregar algún tipo de valor de anotación enabledClass .

Parece indicar cierto desdén hacia el enfoque original que tomó con la semántica @Test (habilitada). Si ese es realmente el caso, ¿por qué no llevar su semántica a algo que creas que es más intuitivo?

De acuerdo, creo que @Test(enabledClass = false) tendría sentido y es la única forma de implementar su sugerencia sin romper la compatibilidad con versiones anteriores. También debería ser bastante fácil.

¿Quizás tú o @juherr estarían interesados ​​en enviar un PR?

No me siento bien. No me gusta la idea de agregar un nuevo atributo que solo se use en la clase.
Entonces, creo que enable=false es una mala práctica cuando se usa en la fuente porque tendrá que modificar las fuentes cuando desee ejecutar las pruebas.
En mi opinión, si desea anular la selección de una clase, se debe usar testng.xml su lugar.
@ecbrodie ¿Cómo se realizan las pruebas?

Por cierto, lo que propongo en su lugar es proporcionar una implementación IAnnotationTransformer que anulará el comportamiento predeterminado de enable=false en la clase.
IAnnotationTransformer solo tiene que enable=false cada prueba si su clase tiene enable=false .
No romperá la compatibilidad con versiones anteriores y no agregará un parámetro específico.
@cbeust ¿Qué opinas?

@juherr Genial PR, de hecho es muy simple de hacer con un IAnnotationTransformer .

Mi única preocupación es que para el usuario, es un poco más arcano de usar, a diferencia de un atributo enabledClass .

Tenga en cuenta que ya tenemos algunos atributos que solo son aplicables a nivel de clase ( suiteName , testName ).

Como dije, no me gusta el caso de uso. Y supongo que será suficiente para las únicas 2 personas que lo pidieron en los 4 últimos años :)

@juherr Bastante justo.

@ecbrodie ¿Qué opinas de las relaciones públicas?

https://github.com/cbeust/testng/pull/816

@cbeust
Sólo curioso. ¿Qué pasa si proporcionamos un AnnotationTransformer integrado que puede hacer esto?

Sí, es lo que propone el # 816

@juherr
Gracias por compartir esa información de relaciones públicas. ¿Alguna razón por la que esto está esperando ser fusionado?

¿Qué pasa si tengo un escenario como el siguiente?

@Test(groups = { "regression", "smoke" }, dependsOnGroups = { "Creation" })
public class EditName {

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class)
    public void TC_1(String Msg) throws Exception{
        System.out.println(Msg);
    }

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class, dependsOnMethods = { "TC_1" }))
    public void TC_2(String Msg) throws Exception{
        System.out.println(Msg);
    }
}

1. ¿TC_1 y TC_2 pertenecerán a ambos, regresión y grupos de humo?
2. ¿Dependerán tanto TC_1 como TC_2 del grupo "Creación"?
3. ¿TC_2 dependerá del grupo "Creación" así como de TC_1, o solo de TC_1?

@ Rameshwar-Juptimath ¿Cuál es la relación entre su muestra y este problema?

Debido a este comportamiento no intuitivo de @Test a nivel de clase y método.
¿Qué debería recomendarse como mejor práctica?
¿Deberíamos evitar usar ambos en las pruebas?
Si lo estamos usando más o menos a nivel de método para tener un proveedor de datos diferente para cada caso, ¿deberíamos evitar tenerlo en la clase?
¿Pensamientos?

@aliciatang El comportamiento es el mismo para todos los atributos de anotación: los valores del método anularán los valores de la clase.

Desde 6.13 puede usar @Ignore que es el comportamiento que espera. La documentación de @Ignore se puede encontrar aquí