TestNG es uno de los marcos de pruebas m\u00e1s utilizados tanto para pruebas unitarias como automatizadas. En esta gu\u00eda hemos reunido algunas de las preguntas m\u00e1s frecuentes y las respuestas a las entrevistas, tanto para los reci\u00e9n llegados al campo como para los m\u00e1s experimentados.<\/p>\n\n
Respuesta: TestNG (NG como Next Generation) es un marco de pruebas que puede integrarse con Selenium o con cualquier otra herramienta de automatizaci\u00f3n para proporcionar m\u00faltiples capacidades, como aserciones, informes, ejecuci\u00f3n paralela de pruebas, etc.<\/p>\n\n
R: Las ventajas de TestNG son:<\/p>\n\n
R: Selenium es una herramienta de automatizaci\u00f3n que podemos utilizar para automatizar aplicaciones web. Para a\u00f1adir capacidades de prueba a las suites de automatizaci\u00f3n de pruebas, Selenium est\u00e1 interconectado con TestNG. Usando TestNG, podemos tener diferentes caracter\u00edsticas en nuestra suite de automatizaci\u00f3n, como diferentes tipos de aserciones, informes, ejecuci\u00f3n paralela, parametrizaci\u00f3n, etc.<\/p>\n\n
En resumen, para realizar pruebas de automatizaci\u00f3n, Selenium ayuda con la \u00abautomatizaci\u00f3n\u00bb y TestNG ayuda con las capacidades de \u00abprueba\u00bb.<\/p>\n\n
R: El archivo testng.xml se utiliza para configurar todo el conjunto de pruebas. En el archivo testng.xml, podemos crear un conjunto de pruebas, crear grupos de pruebas, marcar pruebas para su ejecuci\u00f3n en paralelo, a\u00f1adir oyentes y pasar par\u00e1metros a los guiones de prueba. Tambi\u00e9n podemos utilizar este archivo testng.xml para ejecutar el conjunto de pruebas desde la l\u00ednea de comandos\/terminal o Jenkins.<\/p>\n\n
R: Utilizando el atributo groups en TestNG, podemos asignar m\u00e9todos de prueba a diferentes grupos.<\/p>\n\n
\/\/Testovacia met\u00f3da patriaca len do sanity suite\n\n@Test(groups = {\"sanitySuite\"})\n\npublic void testMethod1() {\n\n \/\/Testovacia logika\n\n}\n\n\/\/Testovacia met\u00f3da patriaca do sady sanity aj regresnej sady\n\n@Test(groups = {\"sanitySuite\", \"regressionSuite\"})\n\npublic void testMethod2() {\n\n \/\/Testovacia logika\n\n}<\/code><\/pre>\n\n<\/p>\n\n
Preguntas 6. \u00bfC\u00f3mo podemos excluir un m\u00e9todo de prueba de la ejecuci\u00f3n mediante el archivo testng.xml?<\/h2>\n\n
R: Utilizando la etiqueta de exclusi\u00f3n en el archivo testng.xml, podemos excluir de la ejecuci\u00f3n un m\u00e9todo de prueba concreto.<\/p>\n\n
<suite name=\"Test Suite\" verbose=\"1\">\n\n <test name=\"TestName\">\n\n <classes>\n\n <class name=\"TestClassName\">\n\n <methods>\n\n <exclude name=\"testMethodToBeExcluded\"\/>\n\n <\/methods>\n\n <\/class> \n\n <\/classes>\n\n <\/test>\n\n<\/suite><\/code><\/pre>\n\n<\/p>\n\n
Preguntas 7. \u00bfCu\u00e1les son algunas de las anotaciones de TestNG m\u00e1s utilizadas?<\/h2>\n\n
Respuesta: Las anotaciones TestNG m\u00e1s utilizadas son:<\/p>\n\n
\n- @Prueba – la anotaci\u00f3n @Prueba identifica al m\u00e9todo como m\u00e9todo de Prueba.<\/li>\n\n\n\n
- @AntesDeSuite – El m\u00e9todo de anotaci\u00f3n s\u00f3lo se ejecuta una vez antes de que se ejecuten todas las pruebas de este conjunto.<\/li>\n\n\n\n
- @Despu\u00e9sDeLaSuite – El m\u00e9todo de anotaci\u00f3n s\u00f3lo se ejecutar\u00e1 una vez despu\u00e9s de que se hayan ejecutado todas las pruebas de esta suite.<\/li>\n\n\n\n
- @AntesDeClase – El m\u00e9todo anotado se ejecuta s\u00f3lo una vez antes de llamar al primer m\u00e9todo de prueba de la clase actual.<\/li>\n\n\n\n
- @AfterClass – El m\u00e9todo anotado se ejecuta s\u00f3lo una vez despu\u00e9s de que se hayan ejecutado todos los m\u00e9todos de prueba de la clase actual.<\/li>\n\n\n\n
@AntesDePrueba – El m\u00e9todo anotado se ejecuta antes de que se ejecute cualquier m\u00e9todo de prueba perteneciente a clases dentro de la etiqueta.<\/test><\/li>\n\n\n\n@AfterTest – El m\u00e9todo anotado se ejecuta despu\u00e9s de que se ejecuten todos los m\u00e9todos de prueba pertenecientes a las clases dentro de la etiqueta.<\/test><\/li>\n\n\n\n- @AntesDeM\u00e9todo – El m\u00e9todo anotado se ejecuta antes de cada m\u00e9todo de prueba anotado con @Prueba.<\/li>\n\n\n\n
- @AfterMethod – El m\u00e9todo anotado se ejecuta despu\u00e9s de cada m\u00e9todo de prueba anotado con @Prueba.<\/li>\n\n\n\n
- @DataProvider – La anotaci\u00f3n @DataProvider se utiliza para pasar datos de prueba al m\u00e9todo de prueba. El m\u00e9todo de prueba se activa por el n\u00famero de filas de datos que pasan por el m\u00e9todo del proveedor de datos.<\/li>\n<\/ul>\n\n
Pregunta 8. \u00bfCu\u00e1l es el orden de ejecuci\u00f3n del m\u00e9todo de prueba en funci\u00f3n de las distintas anotaciones?<\/h2>\n\n
Respuesta: Los m\u00e9todos de prueba en TestNG se ejecutan en el orden Suite->Prueba->Clase->M\u00e9todo combinado con el orden Antes de anotaciones->Prueba de anotaciones->Despu\u00e9s de anotaciones. Por tanto, el orden de ejecuci\u00f3n es el siguiente<\/p>\n\n
@BeforeSuite<\/p>\n\n
@AntesDeLaPrueba<\/p>\n\n
@AntesClase<\/p>\n\n
@M\u00e9todoAnterior<\/p>\n\n
@Prueba<\/p>\n\n
@M\u00e9todoDespu\u00e9s<\/p>\n\n
@AfterClass<\/p>\n\n
@AfterTest<\/p>\n\n
@AfterSuite<\/p>\n\n
Pregunta 9. \u00bfCu\u00e1les son algunas de las afirmaciones comunes que proporciona TestNG?<\/h2>\n\n
Respuesta Algunas de las afirmaciones habituales de TestNG son:<\/p>\n\n
\n- assertEquals(String real, String esperado, String mensaje) y otros tipos de datos sobrecargados en el par\u00e1metro<\/li>\n\n\n\n
- assertNotEquals(double data1, double data2, String message) y otros tipos de datos sobrecargados en el par\u00e1metro<\/li>\n\n\n\n
- assertFalse(condici\u00f3n booleana, mensaje de cadena)<\/li>\n\n\n\n
- assertTrue(condici\u00f3n booleana, mensaje de cadena)<\/li>\n\n\n\n
- assertNotNull(Objeto objeto)<\/li>\n\n\n\n
- fail(condici\u00f3n booleana, mensaje de cadena)<\/li>\n\n\n\n
- true(Mensaje de cadena)<\/li>\n<\/ol>\n\n
Pregunta 10. \u00bfC\u00f3mo podemos desactivar o impedir que se ejecute un caso de prueba?<\/h2>\n\n
Respuesta: Si establecemos el atributo \u00abenabled\u00bb en false, podemos impedir que se ejecute el m\u00e9todo de prueba.<\/p>\n\n
\/\/V pr\u00edpade testovacej met\u00f3dy\n\n@Test(enabled = false)\n\npublic void testMethod1() {\n\n \/\/Testovacia logika\n\n}\n\n\/\/V pr\u00edpade testovacej met\u00f3dy patriacej do skupiny\n\n@Test(groups = {\"NegativeTests\"}, enabled = false)\n\npublic void testMethod2() {\n\n \/\/Testovacia logika\n\n}<\/code><\/pre>\n\n<\/p>\n\n
Pregunta 11. \u00bfC\u00f3mo podemos utilizar TestNG para hacer que un m\u00e9todo de prueba dependa de otros?<\/h2>\n\n
R: Utilizando el par\u00e1metro dependsOnMethods en la anotaci\u00f3n @Test en TestNG, podemos hacer que un m\u00e9todo de prueba se ejecute s\u00f3lo despu\u00e9s de que el m\u00e9todo de prueba dependiente se haya ejecutado correctamente.<\/p>\n\n
@Prueba(dependeDeM\u00e9todos = { \u00abprePruebas\u00bb })<\/strong><\/p>\n\nPregunta 12. \u00bfC\u00f3mo podemos establecer la prioridad de los casos de prueba en TestNG?<\/h2>\n\n
R: Podemos definir la prioridad de los casos de prueba utilizando el par\u00e1metro \u00abprioridad\u00bb en la anotaci\u00f3n @Test. Las pruebas con valores de prioridad m\u00e1s bajos se realizar\u00e1n primero. Ejemplo:<\/p>\n\n
@Prueba(prioridad=1)<\/strong><\/p>\n\nPregunta 13. \u00bfCu\u00e1l es la prioridad por defecto de los casos de prueba en TestNG?<\/h2>\n\n
R: La prioridad de prueba por defecto, si no se especifica, es un valor entero de 0. As\u00ed, si tenemos un caso de prueba con prioridad 1 y otro sin prioridad, se ejecutar\u00e1 primero la prueba sin ning\u00fan valor de prioridad (ya que el valor por defecto ser\u00e1 0 y se ejecutar\u00e1n primero las pruebas con menor prioridad).<\/p>\n\n
Pregunta 14. \u00bfC\u00f3mo podemos ejecutar un m\u00e9todo de prueba varias veces en un ciclo (sin utilizar ning\u00fan proveedor de datos)?<\/h2>\n\n
R: Si utilizas el par\u00e1metro invocationCount y estableces su valor en un n\u00famero entero, el m\u00e9todo de prueba se ejecutar\u00e1 n veces en un ciclo.<\/p>\n\n
<\/p>\n\n
@Test(invocationCount = 10)\n\npublic void invocationCountTest(){\n\n \/\/Testovacia logika\n\n}<\/code><\/pre>\n\nPreguntas 15. \u00bfQu\u00e9 es threadPoolSize? \u00bfC\u00f3mo podemos utilizarlo?<\/h2>\n\n
Respuesta: El atributo threadPoolSize especifica el n\u00famero de hilos a asignar al m\u00e9todo de prueba. Se utiliza junto con el atributo invocationCount. El n\u00famero de hilos se divide por el n\u00famero de iteraciones del m\u00e9todo de prueba especificado en el atributo invocationCount.<\/p>\n\n
<\/p>\n\n
@Test(threadPoolSize = 5, invocationCount = 10)\n\npublic void threadPoolTest(){\n\n \/\/Testovacia logika\n\n}<\/code><\/pre>\n\nPregunta 16. \u00bfCu\u00e1l es la diferencia entre aserci\u00f3n suave y aserci\u00f3n dura en TestNG?<\/h2>\n\n
Respuesta: Esta es una de las preguntas m\u00e1s frecuentes en una entrevista de TestNG. Las aserciones suaves (SoftAssert) nos permiten tener m\u00faltiples aserciones dentro de un m\u00e9todo de prueba, incluso si una aserci\u00f3n falla, el m\u00e9todo de prueba sigue ejecutando el resto de la prueba. El resultado de todas las afirmaciones puede resumirse al final utilizando el m\u00e9todo softAssert.assertAll().<\/p>\n\n
<\/p>\n\n
@Test\n\npublic void softAssertionTest(){\n\n SoftAssert softAssert= new SoftAssert();\n\n \/\/Assertion failing\n\n softAssert.fail();\n\n System.out.println(\"Failing\");\n\n \/\/Assertion passing\n\n softAssert.assertEquals(1, 1);\n\n System.out.println(\"Passing\");\n\n \/\/Collates test results and marks them pass or fail\n\n softAssert.assertAll();\n\n}<\/code><\/pre>\n\nAqu\u00ed, aunque falle la primera aserci\u00f3n, la prueba continuar\u00e1 su ejecuci\u00f3n e imprimir\u00e1 un mensaje bajo la segunda aserci\u00f3n.<\/p>\n\n
Las afirmaciones duras, por otro lado, son las afirmaciones habituales que proporciona TestNG. En el caso de una afirmaci\u00f3n dura, ante cualquier fallo, se detendr\u00e1 la ejecuci\u00f3n de la prueba, impidiendo as\u00ed que se realicen m\u00e1s pasos del m\u00e9todo de prueba.<\/p>\n\n
Pregunta 17. \u00bfC\u00f3mo suspender la prueba en el testNG si no se realiza en el tiempo especificado?<\/h2>\n\n
Respuesta: Podemos utilizar el atributo timeOut de la anotaci\u00f3n @Test. El valor asignado a este atributo timeOut actuar\u00e1 como l\u00edmite superior. Si la prueba no se ejecuta dentro de este plazo, fracasar\u00e1, salvo que se agote el tiempo de espera.<\/p>\n\n
@Test(timeOut = 1000)\n\npublic void timeOutTest() throws InterruptedException {\n\n \/\/Sleep for 2sec so that test will fail\n\n Thread.sleep(2000);\n\n System.out.println(\"Will throw Timeout exception!\");\n\n}<\/code><\/pre>\n\n<\/p>\n\n
Pregunta 18. \u00bfC\u00f3mo podemos omitir condicionalmente un caso de prueba?<\/h2>\n\n
R: Podemos saltarnos condicionalmente un caso de prueba utilizando la funci\u00f3n SaltarExcepci\u00f3n. Cuando se lanza una skipException, el m\u00e9todo de prueba se marca como omitido en el informe de ejecuci\u00f3n de la prueba y no se ejecuta ninguna sentencia despu\u00e9s de lanzar la excepci\u00f3n.<\/p>\n\n
<\/p>\n\n
@Test\n\npublic void testMethod(){\n\n if(conditionToCheckForSkippingTest)\n\n throw new SkipException(\"Skipping the test\");\n\n \/\/test logic\n\n}<\/code><\/pre>\n\nPregunta 19. \u00bfC\u00f3mo podemos asegurarnos de que un m\u00e9todo de prueba se ejecute incluso si los m\u00e9todos de prueba o grupos de los que depende fallan o se omiten?<\/h2>\n\n
R: Utilizando el atributo \u00abalwaysRun\u00bb de la anotaci\u00f3n @Test, podemos asegurarnos de que el m\u00e9todo de prueba se ejecuta incluso si los m\u00e9todos de prueba o grupos de los que depende fallan o se omiten.<\/p>\n\n
@Test\n\npublic void parentTest() { \n\n Assert.fail(\"Failed test\");\n\n}\n\n@Test(dependsOnMethods={\"parentTest\"}, alwaysRun=true) \n\npublic void dependentTest() { \n\n System.out.println(\"Running even if parent test failed\");\n\n}<\/code><\/pre>\n\n<\/p>\n\n
Aqu\u00ed, aunque la prueba padre haya fallado, la prueba dependiente no se omitir\u00e1, sino que se ejecutar\u00e1 debido a \u00abalwaysRun=true\u00bb. Si eliminamos el atributo \u00abalwaysRun=true\u00bb de @Test, el informe mostrar\u00e1 un fallo y una prueba omitida sin intentar ejecutar el m\u00e9todo dependentTest.<\/p>\n\n
Pregunta 20. \u00bfC\u00f3mo podemos pasar un par\u00e1metro de prueba a un script utilizando TestNG?<\/h2>\n\n
R: Utilizando la anotaci\u00f3n @Parameter y la etiqueta \u00abparameter\u00bb en testng.xml, podemos pasar par\u00e1metros a los scripts de prueba.<\/p>\n\n
Muestra testng.xml:<\/p>\n\n
<\/p>\n\n
<suite name=\"sampleTestSuite\">\n\n <test name=\"sampleTest\"> \n\n <parameter name=\"sampleParamName\" value=\"sampleParamValue\"\/>\n\n <classes>\n\n <class name=\"TestFile\" \/>\n\n <\/classes> \n\n <\/test>\n\n<\/suite>\n\nUk\u00e1\u017eka testovacieho skriptu \u2013\n\npublic class TestFile {\n\n @Test\n\n @Parameters(\"sampleParamName\")\n\n public void parameterTest(String paramValue) {\n\n System.out.println(\"Value of sampleParamName is - \" + sampleParamName);\n\n }<\/code><\/pre>\n\nPregunta 21. \u00bfC\u00f3mo podemos crear un marco basado en datos utilizando TestNG?<\/h2>\n\n
R: Utilizando @DataProvider, podemos crear un marco dirigido por datos en el que los datos se pasan al m\u00e9todo de prueba apropiado y se ejecutan m\u00faltiples iteraciones de la prueba para diferentes valores de los datos de prueba pasados desde el m\u00e9todo @DataProvider. El m\u00e9todo anotado por la anotaci\u00f3n @DataProvider devuelve una matriz 2D del objeto.<\/p>\n\n
\/\/Data provider returning 2D array of 3*2 matrix\n\n @DataProvider(name = \"dataProvider1\")\n\n public Object[][] dataProviderMethod1() {\n\n return new Object[][] {{\"kuldeep\",\"rana\"}, {\"k1\",\"r1\"},{\"k2\",\"r2\"}};\n\n }\n\n \/\/This method is bound to the above data provider returning 2D array of 3*2 matrix\n\n \/\/The test case will run 3 times with different set of values\n\n @Test(dataProvider = \"dataProvider1\")\n\n public void sampleTest(String s1, String s2) {\n\n System.out.println(s1 + \" \" + s2);\n\n }<\/code><\/pre>\n\n<\/p>\n\n
Pregunta 22. \u00bfPara qu\u00e9 sirve la anotaci\u00f3n @Listener en TestNG?<\/h2>\n\n
Respuesta: TestNG nos proporciona diferentes tipos de escuchadores con los que podemos realizar una acci\u00f3n cuando se dispara un evento. Normalmente, los listeners de TestNG se utilizan para configurar los informes y el registro. Uno de los escuchadores m\u00e1s utilizados en testNG es la interfaz ITestListener. Tiene m\u00e9todos como onTestSuccess, onTestFailure, onTestSkipped, etc. Tenemos que implementar esta interfaz creando nuestra propia clase oyente. A continuaci\u00f3n, mediante la anotaci\u00f3n @Listener, podemos especificar que nuestra clase listener personalizada debe utilizarse para una clase de prueba concreta.<\/p>\n\n
@Listeners(PackageName.CustomizedListenerClassName.class)\n\npublic class TestClass { \n\n WebDriver driver= new FirefoxDriver();@Test \n\n public void testMethod(){\n\n \/\/testovacia logika\n\n }\n\n}<\/code><\/pre>\n\n<\/p>\n\n
Pregunta 23. \u00bfPara qu\u00e9 sirve la anotaci\u00f3n @Factory en TestNG?<\/h2>\n\n
Respuesta: La anotaci\u00f3n @Factory ayuda en la ejecuci\u00f3n din\u00e1mica de los casos de prueba. Utilizando la anotaci\u00f3n @Factory, podemos pasar par\u00e1metros a toda la clase de prueba en tiempo de ejecuci\u00f3n. Los par\u00e1metros pasados pueden ser utilizados por uno o varios m\u00e9todos de prueba de esta clase.<\/p>\n\n
Por ejemplo, hay dos clases TestClass y TestFactory. Gracias a la anotaci\u00f3n @Factory, los m\u00e9todos de prueba de la clase TestClass se ejecutan dos veces con las entradas \u00abk1\u00bb y \u00abk2\u00bb<\/p>\n\n
public class TestClass{\n\n private String str;\n\n \/\/Constructor\n\n public TestClass(String str) {\n\n this.str = str;\n\n }\n\n @Test\n\n public void TestMethod() {\n\n System.out.println(str);\n\n }\n\n}\n\npublic class TestFactory{\n\n \/\/The test methods in class TestClass will run twice with data \"k1\" and \"k2\"\n\n @Factory\n\n public Object[] factoryMethod() {\n\n return new Object[] { new TestClass(\"K1\"), new TestClass(\"k2\") };\n\n }\n\n}<\/code><\/pre>\n\n<\/p>\n\n
Pregunta 24. \u00bfCu\u00e1l es la diferencia entre la anotaci\u00f3n @Factory y @DataProvider?<\/h2>\n\n
Contesta: El m\u00e9todo @Factory crea una instancia de una clase de prueba y ejecuta todos los m\u00e9todos de prueba de esa clase con un conjunto diferente de datos.<\/p>\n\n
Mientras que @DataProvider se vincula a m\u00e9todos de prueba individuales y ejecuta m\u00e9todos espec\u00edficos varias veces.<\/p>\n\n
Pregunta 25. \u00bfC\u00f3mo podemos utilizar TestNG para ejecutar casos de prueba en paralelo?<\/h2>\n\n
Respuesta: Para ejecutar pruebas en paralelo, s\u00f3lo tienes que a\u00f1adir estos dos pares clave-valor a la etiqueta suite del archivo testng.xml<\/p>\n\n
\n- parallel=\u00bb{m\u00e9todos\/pruebas\/clases}\u00bb<\/li>\n\n\n\n
- thread-count=\u00bb{n\u00famero de hilos que quieres ejecutar al mismo tiempo}\u00bb.<\/li>\n<\/ul>\n\n
<suite name=\u00bbITtester\u00bb parallel=\u00bbm\u00e9todos\u00bb thread-count=\u00bb5″><\/strong><\/p>\n\nCon esto concluye nuestra exhaustiva lista de preguntas para las entrevistas de TestNG. Si quieres saber m\u00e1s sobre TestNG, tambi\u00e9n puedes consultar nuestro completo – Tutorial TestNG.<\/p>\n","protected":false},"excerpt":{"rendered":"
En esta gu\u00eda hemos reunido las preguntas m\u00e1s frecuentes y las respuestas a las entrevistas, tanto para los reci\u00e9n llegados como para los probadores m\u00e1s experimentados.<\/p>\n","protected":false},"author":8,"featured_media":1798,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[33],"tags":[],"class_list":["post-1797","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-preguntas-de-la-entrevista"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/1797","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/comments?post=1797"}],"version-history":[{"count":1,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/1797\/revisions"}],"predecessor-version":[{"id":1802,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/1797\/revisions\/1802"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media\/1798"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media?parent=1797"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/categories?post=1797"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/tags?post=1797"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}