Total PEPE ESE ESE

Indica cual de las siguientes afirmaciones es falsa: Aunque un producto funcione de acuerdo con los requerimientos especificados puede que no satisfaga las expectativas del cliente. Aunque probemos un código utilizando un conjunto de pruebas eficientes y efectivas, y todos los test pasen, no podemos garantizar que el código no presente ningún defecto. Durante el proceso de desarrollo de un producto, cuanto antes se detecte un defecto menos costoso será repararlo. Las pruebas pueden demostrar la ausencia de defectos.

Cualquier librería que sea requerida en el proceso de construcción de un proyecto maven ... si se encuentra en un repositorio remoto, se descarga en el directorio target. si no se encuentra en un repositorio remoto, se busca en el repositorio local. si no se encuentra en un repositorio remoto, se busca en el directorio .m2. todas las afirmaciones anteriores son falsas.

Con respecto al método de caja negra de reparticiones equivalentes, indica cual de las siguientes afirmaciones es cierta: Dos elementos de la misma partición de entrada no se pueden corresponder con dos elementos de particiones de salida diferentes. Todas las entradas y salidas se corresponden con parámetros de la SUT. Las particiones pueden compartir elementos para mantener algunos datos de prueba redundantes. Se deben probar todas las posibles combinaciones de las particiones.

Si en el pom.xml de nuestro proyecto añadimos la siguiente propiedad: <properties> <miPropiedad>misTests</miPropiedad_ </properties> y la siguiente configuracion del pluging maven-surefire-plugin: <configuration> <groups>${miPropiedad}</groups> </configuration> y tiene la siguiente clase con 3 drivers: class MiClaseTest{ @Tag("misTests") @Test void test1(){...} @Tag("otroTest") @Test void test2(){...} @Test void test3(){...} } Si desde la linea de comandos ejecutamos la orden mvn test -DmiPropiedad="". Se ejecutan los 3 drivers. Se ejecuta solo test1(). No se ejecuta ningun driver porque en la orden no se indica ninguna etiqueta. Se ejecuta solo test3().

Dado el siguiente driver para probar metodoSUT(): @Test (expected = MiExcepcion.class) public void testC1(){ int resultadoEsperado = 0; int resultadoReal = metodoSUT(); AssertEquals(resultadoEsperado, resultadoReal); }. Failed, si el metodoSUT() provoca la excepcion MiExcepcion.class. Passed, si el metodoSUT() provoca la excepcion MiExcepcion.class. Passed, si el metodoSUT() devuelve 0. Error, si el metodoSUT() provoca la excepcion MiExcepcion.class.

Cuando refactorizamos la SUT para poder inyectar el doble. Si añadimos un metodo setter estamos obligando a cualquier codigo cliente de la SUT a conocer dicha dependencia antes de invocarla. Si añadimos un parametro a la SUT estamos obligados a declarar la dependencia como atributo de la clase que contiene la SUT. Si añadimos una factoria local, alteraremos el compartamiento de la clase que contiene la SUT. Si añadimos una clase factoria no se altera el codigo de producción.

En un metodo de diseño de pruebas basado en el flujo de control de código, un camino imposible detectado. no se asocia a ningun caso de prueba. se asocia a un caso de prueba con un resultado esperado desconocido. se asocia a un caso de prueba con valores de entrada desconocidos. todas las afirmaciones del resto de ocpciones son falsas.

Indica cual de las siguientes afirmaciones es falsa acerca del uso de categorias en JUnit. Se anota como categoría un metodo anotado como @test. Se anota como categoría una clase que contiene drivers. Se anota como categoría una interfaz. Se anota como categoría varios drivers de una clase.

Indica cual de las siguientes afirmaciones es cierta con respecto a estos 3 tipos de objeto: Podemos crear una librería EasyMock: NiceMock, Mock y StrictMock. Con los tres tipos siempre hay que invocar al metodo Verify() de la librería. Con los tipos Mock y StrictMock se verifican el orden en el que se realizan las invocaciones al doble. Con los tipos Mock y NiceMock se lanza un AssertionError si no hemos programado las expect de algún método. Con los tres tipos se verifica si todas las llamadas esperadas a metodos realizados por el doble se realizan con los argumentos especificados.

Utilizando un método de caja negra de particiones equivalentes, si tenemos una entrada asociada a un tipo enumerado con 3 valores, indica cual de las siguientes afirmaciones es falsa: Podemos tener tres particiones no validas de dicha entrada. Podemos tener una sola particiones validas de dicha entrada. Podemos tener tres particiones validas de dicha entrada. Podemos tener tres particiones validas de dicha entrada.

Dado el siguiente diagrama de Venn que hemos trabajado en clase: Indica cual de las siguientes afirmaciones es cierta: Un tester debe intentar que el subconjunto 7 sea lo mas grande posible. Con metodos de caja blanca y caja negra, se puede alcanzar comportamientos de los subconjuntos 1 y 2. Con un metodo de caja negra se pueden alcanzar comportamientos de subconjunto 3. Con un metodo de caja blanca se pueden alcanzar comportamientos de subconjunto 4.

Con cual de los siguientes comandos de Maven no se ejecutaran las pruebas unitarias. mvn test-compile surefire:test. mvn test. mvn clean test-compile surefire:test. mvn clean compile surefire:test.

Si al aplicar el metodo de caja negra de particiones equivalentes obtendremos las siguientes particiones de entradas validas y no validas, teniendo en cuenta la siguiente codificacion para identificar las particiones: "E" denota entrada, "V" valida y "VN" no valida. Indica cual es la cardinalidad del conjunto de casos de prueba eficiente y efectivo al aplicar dicho metodo: Entrada 1: "E1V1, E1V2, E1NV1" Entrada 2: "E2V1, E2NV1, E2NV2". 5. 6. 4. No se puede obtener si no se conocen las particiones de salida validas y no validas.

Al ejecutar una clase de test que contiene n drivers: El método anotado con @AfterEach se ejecutara n+1 veces. El método anotado con @BeforeAll se ejecutara 1 vez. El método anotado con @AfterAll se ejecutara n veces. El método anotado con @BeforeEach se ejecutara n-1 veces.

De los comandos maven, cuales generan el .jar del proyecto? comando 1: mvn clean compiler:testCompile package comando 2: mvn clean compile package comando 3: mvn clean test-compile package comando 4: mvn clean verify comando 5: mvn clean compiler:compile verify. todos los comandos. los comandos 1, 2 y 3. los comandos 4 y 5. los comandos 2, 3, 4 y 5.

Dado el siguiente metodo que devuelve el sumatorio desde 1 hasta un determinado valor n: int sumatorio(int n){ int suma = 0; for(int i=1; i <= 0; i++){ suma += 1; } return suma; } Se puede aplicar el método del camino básico>. Con uno o 2 caminos. Al contener un bucle cuyo numero de iteraciones depende del valor de entrada n, no podemos saber el numero de caminos. Con n caminos. Con mas de 2 caminos.

Para realizar pruebas unitarias utilizando verificacion basada en el comportamiento de la SUT compruebaPremio(), indica los tipos y numero de mocks necesarios>. Un PartialMock y un Mock. Un StrictMock, un PartialMock y un Mock. Un StrictMock y un PartialMock. Un StrictControl y dos StrickMock.

Indica cual de las siguientes afirmaciones es cierta: Si es necesario, se puede alterar temporalmente el codigo de la SUT para realizar pruebas. Si es necesario, refactorizamos la SUT para eliminar sus dependencias externas. Un doble reemplaza al codigo real de una dependencia externa durante las pruebas. Un SEAM es un punto de inyeccion del doble.

El artefacto maven con las siguientes coordenadas: ppss.examen:ejemplo:war:1.0-SNAPSHOT Representa el fichero: $HOME/.m2/repository/ppss/examen/ejemplo/1.0-SNAPSHOT/ejemplo-1.0-SNAPSHOT.war. $HOME/.m2/repository/ppss/examen/ejemplo-1.0-SNAPSHOT.war. $HOME/.m2/repository/ppss/examen/ejemplo/ejemplo-1.0-SNAPSHOT.war. $HOME/.m2/repository/ppss/examen/ejemplo/war/1.0-SNAPSHOT/ejemplo.

Con el metodo del camino basico de McCabe: Debemos elegir el conjunro minimo de caminos para conseguir que todas las sentencias se ejecuten al menos una vez en cada caso de prueba. Todas las afirmaciones del resto de opciones son falsas. Debemos elegir el conjunto minimo de caminos para conseguir ejecutar todas las condiciones al menos una vez en cada caso de prueba. Debemos elegir todos los caminos del grafo.

Indica cual es la complejidad ciclomatica del siguiente codigo: if(a > b && a< c || c < b) a = b; else if(a < b || c > a) c = = a; else b = c;. 6. 4. 3. 5.

El método de diseño de transición de estados. Requiere que hayamos implementado todas las unidades para poder aplicarlo. Al igual que el método del camino básico se aplica en pruebas dinámicas. Es un método funcional y por lo tanto lo podemos aplicar en cualquier nivel de pruebas. Representa las transiciones a partir de entradas y acciones.

Indica cuál de las siguientes afirmaciones es falsa con respecto al uso de un objeto de tipo IMocksControl: No permite el uso de partial mock. Permite chequear el orden de invocaciones entre varios dobles. No permite el uso de verify(). Permite chequear el orden de las invocaciones de un doble.

Para realizar pruebas de una SUT que contiene dependencias externas,. usaremos una verificación basada en el estado para pruebas unitarias, y una verificación basada en el comportamiento para pruebas de integración. todas las afirmaciones del resto de opciones son falsas. el primer paso es identificar los seams que contiene la SUT. no está permitido modificar la SUT de ninguna forma para realizar pruebas unitarias.

Indica cuál de las siguientes afirmaciones es cierta: los defectos del software que no han sido detectados con las pruebas unitarias, serán detectados con las pruebas de integración. con pruebas de integración no se pueden detectar errores en las unidades a integrar. las pruebas unitarias son dinámicas y las pruebas de integración son estáticas. todas las afirmaciones del resto de opciones son falsas.

Indica cuál de las siguientes afirmaciones es cierta: un proyecto maven con un empaquetado "pom" debe incluir la etiqueta <parent> en su pom.xml. un proyecto maven con un empaquetado "pom" no tiene asociada por defecto ninguna goal a la fase test. el mecanismo reactor de maven permite que un proyectos hijo hereden elementos de la configuración del proyecto padre. todas las afirmaciones del resto de opciones son falsas.

Indica cuál de las siguientes afirmaciones es cierta: la etiqueta <modules> en un aggregator pom permite que los módulos indicados hereden su configuración (propiedades, dependencias, y otros elementos). todas las afirmaciones del resto de opciones son falsas. el mecanismo reactor de maven permite que los proyectos hijo hereden elementos de la configuración del proyecto padre. para establecer una relación de agregación entre proyectos maven, no es necesario usar la etiqueta <parent>.

En un plan de un proyecto software: Las pruebas unitarias, integración, y sistema, no se realizan siempre en ese orden, dependerá del modelo de proceso aplicado y del horizonte de planificación. Las pruebas unitarias, integración, y sistema, no se realizan siempre en ese orden, dependerá de si usamos una planificación adaptativa o predictiva. Las pruebas unitarias, integración, y sistema, se realizan siempre en ese orden. Todas las afirmaciones del resto de opciones son falsas.

Con respecto a las pruebas de aceptación: el diseño de las pruebas lo realiza el propio cliente. tienen como objetivo encontrar defectos porque son pruebas dinámicas. el código a probar es el mismo que en las pruebas del sistema. todas las afirmaciones del resto de opciones son falsas.

Indica cuál de las siguientes afirmaciones es cierta: todas las afirmaciones del resto de opciones son falsas. en una estrategia de integración top-down los componentes de la lógica de negocio serán los menos probados. en cualquier estrategia de integración las últimas unidades integradas serán las más probadas. en una estrategia de integración bottom-up los componentes de la interfaz de usuario serán los primeros en integrarse.

respecto a Webdriver: es una librería que sustituye al navegador durante las pruebas. es una librería usada para pruebas de escenarios. es una API que se puede usar como una alternativa a JMeter. todas las afirmaciones del resto de opciones son falsas.

Dado el siguiente fragmento de código en Java: if (x > 5 & y < 2) { x = x + 1; } if (y > 0) { x = x + 2; } else { x = x + 3; } y dados los datos de entrada para los siguientes casos de prueba: Caso 1: x = 4, y = 2 Caso 2: x = 6, y = -1 y teniendo en cuenta los niveles 1 y 3 de cobertura, indica cuál o cuáles de estos niveles se cumplen: sólo el nivel 3. niveles 1 y 3. ninguno de estos niveles. sólo el nivel 1.

En un plan de pruebas: El diseño de las pruebas siempre es anterior a su implementación, excepto en BDD. Podemos separar los procesos de diseño e implementación, pero no su orden. El diseño de las pruebas no condiciona la calidad de las pruebas si conseguimos niveles altos de cobertura. Podemos omitir alguno de los niveles de pruebas y cambiar su orden si fuese necesario.

Indica cuál es el valor para del contador de líneas a nivel de clase, según el siguiente informe de JaCoCo. 0,30. 0,70. 0,75. ninguno de los valores indicados en el resto de opciones.

A partir de este informe de JMeter obtenido con la siguiente configuración del elemento Thread Group: Number of Threads (users): 1 Loop Count: 1 Indica en qué instante (expresado en segundos) termina su ejecución el usuario: 3. 6. 2. no se puede saber porque falta en la configuración el valor Ramp-up.

Indica cuál de las siguientes afirmaciones es falsa: durante el proceso de desarrollo de un producto, cuanto antes se detecte un defecto menos costoso será repararlo. las pruebas pueden demostrar la ausencia de defectos. aunque probemos un código utilizando un conjunto de pruebas eficiente y efectivo y todos los tests pasen, no podemos garantizar que el código no presenta ningún defecto. aunque un producto funcione de acuerdo a los requerimientos especificados puede que no satisfaga las expectativas del cliente.

Dado el siguiente plan JMeter que es ejecutado por un sólo usuario con las siguientes configuraciones:Thread Properties Loop Count: 3 En ambos Loop Controller Loop Count: 2. 1. 7. 3. 5.

En un plan de un proyecto software: Las pruebas unitarias, integración, y sistema, no se realizan siempre en ese orden, dependerá de si usamos una planificación adaptativa o predictiva. Las pruebas unitarias, integración, y sistema, se realizan siempre en ese orden. Todas las afirmaciones del resto de opciones son falsas. Las pruebas unitarias, integración, y sistema, no siempre se realizan en ese orden, dependerá del modelo de proceso aplicado y del horizonte de planificación.

Indica cuál de las siguientes afirmaciones es cierta: las pruebas unitarias son dinámicas y las pruebas de integración son estáticas. todas las afirmaciones del resto de opciones son falsas. con pruebas de integración no se pueden detectar errores en las unidades a integra. los defectos del software que no han sido detectados con las pruebas unitarias, serán detectados con las pruebas de integración.

Indica cuál de las siguientes afirmaciones es cierta: los objetos de tipo WebElement se instancian con el constructor de una Page Object cuando se usa la clase PageFactory. todas las afirmaciones del resto de opciones son falsas. si no usamos la clase PageFactory, hay que localizar los elementos de las páginas con la anotación @FindBy. cuando utilizamos la clase PageFactory, los elementos de las páginas se localizan con el método findElement().

Un test que use Webdriver con maven: puede implementarse en src/main. puede ejecutarse durante la fase test. necesariamente se debe ejecutar durante la fase verify. todas las afirmaciones del resto de opciones son falsas.

Teniendo en cuenta el proyecto matriculación usado en prácticas: Podemos integrar DAO + PROXY usando alguna estrategia de integración. Podemos integrar DAO + PROXY usando una estrategia de integración. No podemos hacer pruebas unitarias sobre el módulo DAO ya que necesitamos acceder a una BD. Sobre BO podemos realizar tanto pruebas unitarias como de integración.

¿Cuál de las siguientes afirmaciones es falsa sobre las ventajas de la integración continua (CI): Normalmente, los errores serán más fáciles de resolver. Permite que los programadores no tengan que ejecutar las pruebas unitarias en su equipo. El proceso de encontrar errores es menos costoso. Requiere automatizar el proceso de construcción.

Indica cuál de las siguientes afirmaciones es cierta: Las anotaciones DBUnit son necesarias para ejecutar los tests de integración. Un test DBUnit no necesariamente usa la clase Assertion, puede usar la clase Assertions de JUnit. El plugin sql lo hemos usado para inicializar el estado de la BD en cada uno de los tests. La cadena de conexión con la BD se usa solamente en las tests y en el pom.

A partir de este informe de JMeter obtenido con la siguiente configuración del elemento Thread Group: Number of Threads (users): 1 Loop Count: 2 Indica en qué instante (expresado en segundos) termina su ejecución el usuario: 2,2. 1,1. 3,3. no se puede saber porque falta en la configuración el valor Ramp-up.

Dado el siguiente fragmento de código en Java: if (x > 5 & y < 2) { x = x + 1; } if (y > 0) { x = x + 2; } else { x = x + 3; } y dados los datos de entrada para los siguientes casos de prueba: Caso 1: x = 4, y = -1 Caso 2: x = 6, y = 2 y teniendo en cuenta los niveles 1 y 3 de cobertura, indica cuál o cuáles de estos niveles se cumplen: sólo el nivel 3. niveles 1 y 3. ninguno de estos niveles. sólo el nivel 1.

Indica cuál de las siguientes afirmaciones es cierta: todas las afirmaciones del resto de opciones son falsas. cuando utilizamos la clase PageFactory, no creamos una page object usando new(). cuando utilizamos la clase PageFactory, el método initElements() tenemos que invocarlo desde el constructor de la page object asociada a la página principal. es conveniente que los objetos de tipo Alert sean manejados en el código de los tests.

En un test (plan) JMeter: No es necesario usar un servidor proxy si nuestros tests solo usan peticiones http POST. Si usamos un servidor proxy tendremos que cambiar la configuración del navegador para ejecutar el plan. Todas las afirmaciones del resto de opciones son falsas. Si usamos un servidor proxy podremos ejecutar las pruebas aunque el servidor real no esté en ejecución.

Con respecto a las pruebas de aceptación: el diseño de las pruebas lo realiza el propio cliente. el código a probar es el mismo que en las pruebas del sistema. tienen como objetivo encontrar defectos porque son pruebas dinámicas. todas las afirmaciones del resto de opciones son falsas.

Indica cuál es el valor para el contador de complejidad ciclomática a nivel de clase, según el siguiente informe de JaCoCo: 0,80. 0,20. 0,30. ninguno de los valores indicados en el resto de opciones.

Indica cuál de las siguientes afirmaciones es cierta: La etiqueta <modules> en un aggregator pom permite que los módulos indicados hereden su configuración (propiedades, dependencias y otros elementos). Para establecer una relación de agregación entre proyectos Maven, no es necesario usar la etiqueta <parent>. El mecanismo reactor de Maven permite que los proyectos hijos hereden elementos de la configuración del proyecto padre. Todas las afirmaciones son falsas.

Dada la clase DataArray con los siguientes atributos: private int[] coleccion; private int numElem; y dado el siguiente prototipo del metodo de dicha clase: public void delete(int elemento) throws DataException; En un driver en el que queremos comprobar que el resultado de borrar el numero 5 en una coleccion vacia, provoca que lance la excepcion DataException con el mensaje asociado "No hay elementos en la colecion", es adecuado usar los siguientes assert: asserAll( DataException exception = assertThrows(DataException.class, ()-> dataArray.delete(5)); assertEquals("No hay elementos en la colecion", excepcion.getMessage()));. DataException exception = assertThrows(DataException.class, ()-> dataArray.delete(5)); assertEquals("No hay elementos en la colecion", excepcion.getMessage());. assertThrows(DataException.class, ()-> dataArray.delete(5)); assertAll(assertEquals("No hay elementos en la colecion", excepcion.getMessage()));. Ninguna de las opciones anteriores son correctas, puesto que es necesario usar un bloque try...catch.

Si el valor de CC de un CFG es 6 y obtenemos 5 caminos independientes: Eso no es posible, nos falta un camino. Obtendremos una tabla de casos de prueba efectiva, pero no eficiente. El conjunto de comportamientos a probar recorrera todas las sentencias de nuestra SUT. Nos faltaran lineas por recorrer.

Con respecto al metodo de caja negra de particiones equivalentes, indica cual de las siguientes afirmaciones es cierta: todas las entradas y salidas se corresponden con parametros de la SUT. dos elementos de la misma particion de entrada no se pueden corresponder con dos elementos de particiones de salida diferentes. las particiones pueden compartir elementos para mantener algunos datos de prueba redundantes. se deben probar todas las posibles combinaciones de particiones.

Cuando refactorizamos la SUT para poder inyectar el doble: si usamos una clase factoria, estariamos añadiendo una dependencia externa nueva. si usamos EasyMock, no es necesario refactorizar si creamos un mock parcial. dependiendo del tipo de refactorizacion, estaremos cambiando el comportamiento de la SUT. es necesaria cambiar el nombre de la clase que contiene la SUT.

Sobre los test parametrizados: se ejecutan tantas veces como numero de parametros tengan. es posible que para una misma tabla necesitemos implementar mas de un test parametrizado. no podemos usar @BeforeEach si usamos test parametrizados. los test parametrizados deben implementarse en clases separadas.

¿Cuál de los 7 principios de las pruebas (testing) afirma que es imposible ejecutar todas las combinaciones posibles de entradas y precondiciones en un sistema complejo?. Las pruebas demuestran la presencia de defectos, no su ausencia. Las pruebas exhaustivas son imposibles. Las pruebas demuestran la presencia de defectos, no su ausencia. Los defectos se agrupan (defects cluster together).

Verdadero o falso: Un 100% de cobertura de condiciones no garantiza un 100% de cobertura de líneas. Verdadero. Falso.

Verdadero o falso: La velocidad es una métrica de seguimiento que nos permite calcular la duración restante de un proyecto. Verdadero. Falso.

Verdadero o falso: Un servidor de integraciones continuas planifica las construcciones del sistema por nosotros, las 24 horas del día. Verdadero. Falso.

Completa la frase: A partir del código fuente, se dibuja el ______ y se calcula su ______ para determinar el número de caminos independientes a probar. diagrama de clases / número de aristas. grafo de flujo de control / complejidad ciclomática. diagrama de flujo / cobertura de sentencias. árbol de sintaxis abstracta / número de nodos.

Un grafo de flujo de control tiene 8 nodos (N) y 9 aristas (E). ¿Cuál es su Complejidad Ciclomática (CC)?. 19. 3. 2. 1.

Según la pirámide de la automatización de pruebas de Mike Cohn, ¿en qué nivel se debería concentrar la mayor parte del esfuerzo de automatización?. En el medio (Tests de Servicio / Integración), porque verifican la comunicación entre componentes. En la base (Tests Unitarios), porque son rápidos, estables y aíslan los fallos con precisión. El esfuerzo debe ser el mismo en todos los niveles. En la cima (Tests de UI / End-to-End), porque prueban el sistema completo.

La estructura de un buen caso de prueba unitario a menudo sigue el patrón 'Arrange, Act, Assert' (AAA). ¿Qué se hace en la sección 'Arrange'?. Se limpian los recursos utilizados por el test, como cerrar conexiones a bases de datos. Se inicializan los objetos, se configuran los dobles de prueba (stubs/mocks) y se prepara el estado inicial necesario para el test. Se invoca el método de la SUT que se está probando. Se comprueba que el resultado obtenido es el esperado.

En un proyecto Maven, ¿qué plugin se utiliza por defecto para ejecutar los tests unitarios y en qué fase se activa?. Plugin 'compiler' en la fase 'compile'. Plugin 'surefire' en la fase 'test'. Plugin 'failsafe' en la fase 'integration-test'. Plugin 'jar' en la fase 'package'.

Para verificar que un método lanza una excepción específica, ¿cuál de las siguientes aserciones de JUnit 5 es la más adecuada?. `Assertions.assertTrue(miMetodo().lanzaExcepcion());`. `Assertions.assertThrows(MiExcepcion.class, () -> { miMetodo(); });`. `try { miMetodo(); Assertions.fail("Debería haber lanzado una excepción"); } catch (MiExcepcion e) { /* Test pasa */ }`. `Assertions.assertDoesNotThrow(() -> { miMetodo(); });`.

Se quiere crear una `Run Configuration` en Maven para ejecutar únicamente los tests de la clase `DataArrayTest` que estén etiquetados como 'conExcepciones' y 'parametrizado'. ¿Cuál de los siguientes comandos es el correcto?. mvn test -Dtest=DataArrayTest -Dgroups="conExcepciones , parametrizado". mvn test -Dtest=DataArrayTest -Dgroups="conExcepciones & parametrizado". mvn test -Dtest=DataArrayTest -Dgroups="conExcepciones | parametrizado". mvn test -Dtest=DataArrayTest -DincludeTags="conExcepciones,parametrizado".

Completa la frase: Un buen test unitario debe ser FIRST, que son las siglas en inglés de: Fast, Independent, ______, Self-Validating, y Timely. Reusable (Reutilizable). Repeatable (Repetible). Robust (Robusto). Readable (Legible).

La técnica de Particiones Equivalentes se basa en la suposición de que... Solo los valores en los límites de una partición pueden encontrar errores. Todos los valores de una partición se procesan de la misma manera por el sistema. Es necesario probar cada valor de cada partición para estar seguros. Las particiones inválidas son más importantes que las válidas.

Según la técnica de particiones equivalentes, ¿cuál es la regla principal para combinar particiones de entrada inválidas?. Las particiones inválidas no se combinan, se prueban de forma aislada. Cada caso de prueba debe ejercitar exactamente una y solo una partición de entrada inválida. Se deben combinar tantas particiones inválidas como sea posible. Las particiones inválidas solo deben combinarse con particiones válidas de otras entradas.

En el método `generaEventos`, la entrada es un objeto `HorarioAsignatura`. ¿Por qué es necesario agrupar algunas de sus entradas para definir las particiones?. Porque todas las entradas son del mismo tipo de objeto. Porque el resultado esperado depende de la combinación de sus valores (p. ej., si `diaSemana` está dentro de `fechaInicio`-`fechaFin`). Porque la heurística de caja negra obliga a agrupar siempre las entradas de fecha. Para reducir el número total de particiones y simplificar la tabla.

¿Cuál es la diferencia fundamental entre un 'stub' y un 'mock' en términos de lo que verifican?. Los stubs se usan en pruebas unitarias y los mocks en pruebas de integración. Un stub verifica el estado final del SUT o el valor que devuelve (verificación de estado), mientras que un mock verifica que la SUT interactúa con sus dependencias de una manera específica (verificación de comportamiento). No hay ninguna diferencia, son dos nombres para el mismo tipo de doble de prueba. Un stub solo puede devolver valores, mientras que un mock solo puede lanzar excepciones.

¿Cuál de las siguientes afirmaciones representa mejor el objetivo de las pruebas dinámicas?. Demostrar la ausencia de errores en el sistema. Ejecutar el código para evidenciar la presencia de defectos. Encontrar defectos sin necesidad de ejecutar el código. Validar que el código sigue el estándar de codificación.

¿Cuál de los siguientes principios justifica que las pruebas deben ejecutarse lo antes posible en el ciclo de vida del software?. La paradoja del pesticida. El coste creciente de los defectos con el tiempo. Clustering de defectos. La falacia de la ausencia de errores.

¿Cuál de las siguientes opciones es válida para calcular la complejidad ciclomática de un programa estructurado?. Número de líneas de código + 1. Número de nodos – número de aristas – 2. Número de condiciones lógicas + 1. Número de comentarios en el código.

En el método del camino básico, ¿cuál es el objetivo al obtener caminos independientes?. Detectar todos los errores de la SUT. Ejecutar cada instrucción al menos una vez. Ejecutar cada camino posible del CFG. Reducir el número de líneas del código.

¿Cuál es el resultado de ejecutar el siguiente fragmento si no se lanza la excepción esperada?. El test pasa. Se lanza una excepción de tipo AssertionFailedError. El test ignora el fallo. El código se ejecuta pero no se genera informe.

¿Cuál es el propósito principal de un servidor de integración continua como Jenkins o GitLab CI?. Controlar el acceso de los desarrolladores al repositorio. Ejecutar manualmente las pruebas antes de cada despliegue. Automatizar tareas del ciclo de vida como compilación, test y despliegue. Garantizar la generación de documentación en PDF.

¿Cuál de las siguientes fases pertenece al ciclo de vida por defecto de Maven?. configure. compile. execute. prepare.

¿Qué directorio contiene por convención los archivos fuente de prueba en un proyecto Maven?. /src/main/test. /test. /src/test/java. /src/tests.

En la técnica de particiones equivalentes, ¿qué representa una clase de equivalencia válida?. Una clase que produce siempre una excepción. Un subconjunto de valores que se espera que se comporten igual. Una condición que siempre se evalúa a falso. Un conjunto de pruebas negativas.

¿Qué tipo de doble de prueba permite verificar si un método ha sido llamado con ciertos parámetros?. Dummy. Mock. Stub. Spy.

¿Qué afirmación describe correctamente un NiceMock en EasyMock?. Falla si se llama un método no programado. Devuelve valores por defecto sin fallar. Lanza excepción por cualquier llamada inesperada. Solo permite llamadas si se han definido en orden exacto.

¿Cuál de las siguientes técnicas de cobertura estructural se considera más exigente?. Cobertura de sentencias. Cobertura de condiciones. Cobertura de decisiones. Cobertura de condición-decisiones múltiples (MCDC).

¿Qué tipo de cobertura se logra si cada posible resultado booleano de cada subcondición se ha probado al menos una vez?. Cobertura de decisiones. Cobertura de condiciones. Cobertura de sentencias. Cobertura de ramas.

Si al analizar un método obtenemos un valor de cobertura de decisiones del 80%, ¿qué significa?. Se han ejecutado el 80% de las líneas del método. Se han recorrido el 80% de las decisiones posibles (true y false). Se han probado todas las condiciones, pero no todas las combinaciones. El código está completamente cubierto.

¿Qué mide la métrica de “densidad de defectos”?. El número de líneas de código defectuosas dividido por el tiempo de ejecución. La proporción de casos de prueba erróneos frente a los válidos. La cantidad de defectos por unidad de tamaño del software (LOC o FP). El número de defectos detectados por desarrollador.

¿Qué mide la cobertura de condición-decisiones múltiples (MCDC)?. Que cada condición independiente afecte al resultado de la decisión. Que todas las líneas de código se ejecuten. Que todas las decisiones se tomen al menos una vez. Que se prueben todos los posibles valores de los inputs.

¿Cómo se configura JaCoCo para que genere automáticamente el informe HTML tras mvn verify?. Añadiendo <generateHtml>true</generateHtml> en la sección properties. Configurando el plugin jacoco-maven-plugin con report en la fase verify. Usando el goal jacoco:dump en compile. Añadiendo la dependencia de JaCoCo en dependencies.

¿Qué representa la métrica Branch Coverage en JaCoCo?. Porcentaje de sentencias ejecutadas. Porcentaje de caminos posibles ejecutados. Porcentaje de decisiones (true/false) ejecutadas. Porcentaje de clases cubiertas.

¿Qué significa tener 90% de instruction coverage pero solo 50% de branch coverage?. Se han cubierto todas las condiciones. Se han cubierto casi todas las líneas, pero no todas las decisiones. El código tiene pocas condiciones lógicas. Todas las funciones han sido llamadas.

¿Qué genera el comando mvn clean package en un proyecto Java estándar?. Compila y lanza pruebas. Elimina archivos y crea un .jar o .war. Solo genera el informe JaCoCo. Genera un archivo .pom de dependencias.

¿Qué función tiene el plugin surefire en Maven?. Compilar clases. Crear archivos jar. Ejecutar pruebas unitarias. Descargar dependencias.

¿Qué archivos suele generar la ejecución de mvn verify si están configurados jacoco y surefire?. *.java, pom.xml. /target/*.class, /target/site/jacoco/index.html. test-results.xml en raíz. /src/main/resources/tests.html.

¿Qué objetivo tiene el plugin failsafe en comparación con surefire?. Ejecutar tests unitarios. Ejecutar tests de integración. Compilar recursos. Verificar la documentación.

¿Qué patrón suele usarse para evitar modificar datos reales en pruebas de integración?. Page Object. DAO. Rollback automático y base de datos de prueba. Interceptor de HTTP.

¿Qué anotación permite configurar un dataset inicial en una prueba de integración con BBDD (ej. JUnit + DBUnit)?. @DBDataSet. @BeforeTest. @InitData. @BeforeEach.

¿Qué diferencia principal hay entre un stub y un mock?. El stub se usa para pruebas de rendimiento. El stub devuelve respuestas fijas; el mock permite verificar interacciones. Los stubs se generan automáticamente, los mocks no. No hay diferencia.

¿Cómo se puede crear un stub en Java manualmente?. Usando @Mock. Implementando la interfaz objetivo y devolviendo valores predecibles. Usando Mockito.stub(). Mediante reflexión.

¿Qué hace PageFactory.initElements(driver, PageClass.class) en Selenium?. Ejecuta todos los test en el navegador. Cierra el navegador tras las pruebas. Crea instancias automáticas de elementos @FindBy. Reinicia el servidor web.

¿Qué orden correcto debe seguirse en el pom.xml para evitar que Jacoco genere informes si los tests fallan?. Primero jacoco:report, luego failsafe:verify. Primero failsafe:verify, luego jacoco:report-integration. Primero surefire:test, luego jacoco:prepare-agent. Primero verify, luego integration-test.

¿Dónde se almacenan por defecto los ficheros de cobertura generados por Jacoco para test de integración?. target/jacoco.exec. target/site/jacoco-it.exec. target/jacoco-it.exec. target/reports/jacoco.html.

El plugin maven-surefire-plugin se usa principalmente para: Ejecutar pruebas de integración. Medir cobertura. Ejecutar tests unitarios con JUnit. Ejecutar tests de carga con JMeter.

¿Qué propiedad permite seleccionar clases específicas para ejecutar con Maven?. -Dgroup. -Dfilter. -Dtest. -Dskip.

¿Qué hace la goal test-compile en Maven?. Ejecuta los tests. Compila el código fuente y los tests. Ejecuta integración. Compila solo los tests.

¿Qué clase de Selenium permite inicializar automáticamente elementos de página con anotaciones?. WebDriverWait. PageFactory. RemoteWebDriver. WebDriverManager.

¿Qué hace la anotación @FindBy en Selenium?. Lanza una excepción si no encuentra el elemento. Define un selector para ubicar un elemento en la página. Crea un mock del elemento web. Permite seleccionar elementos en archivos XML.

¿Qué elemento debe configurarse en Maven para activar la recolección de cobertura con Jacoco desde el inicio de la ejecución?. jacoco:check. jacoco:prepare-agent. jacoco:report. jacoco:init.

¿Cuál es el resultado si ejecutamos mvn verify sin haber ejecutado antes mvn clean y hay ficheros antiguos en /target?. Se actualizan automáticamente. El proyecto falla en compilación. Se pueden usar resultados obsoletos, generando fallos no reproducibles. No ocurre nada porque Maven limpia solo.

¿Este bloque de test está correctamente definido para comprobar que se lanza una excepción con mensaje esperado? @Test void testDeleteEnVacio() { DataArray dataArray = new DataArray(); DataException exception = assertThrows(DataException.class, () -> { dataArray.delete(5); }); assertEquals("No hay elementos en la coleccion", exception.getMessage()); }. Sí, el bloque está correctamente implementado. Falla porque assertEquals debe estar dentro de assertAll. Falla porque delete() no lanza la excepción en tiempo de ejecución. Falla porque assertThrows no captura el mensaje correctamente.

¿Cuál de los siguientes bloques es el único correcto para comprobar dos aserciones sin que se interrumpa si una falla?. assertEquals(10, resultado); assertTrue(resultado > 5);. assertAll( () -> assertEquals(10, resultado), () -> assertTrue(resultado > 5) );. assertThrows(() -> assertEquals(10, resultado), () -> assertTrue(true));. assertEqualsAll(() -> assertEquals(10, resultado), () -> assertTrue(resultado > 5));.

El siguiente fragmento configura Jacoco para generar informe tras las pruebas. ¿Qué fase se está usando? <plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <executions> <execution> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>report</id> <phase>verify</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin>. La fase test. La fase compile. La fase verify. La fase install.

En EasyMock, ¿cuál de los siguientes mocks lanzará error si se llama a un método no esperado y en orden incorrecto?. ISocioDAO dao = EasyMock.niceMock(ISocioDAO.class);. ISocioDAO dao = EasyMock.mock(ISocioDAO.class);. ISocioDAO dao = EasyMock.strictMock(ISocioDAO.class);. ISocioDAO dao = new SocioDAODummy();.

¿Cuál es el problema de este test? @Test void testException() { assertThrows(DataException.class, dataArray.delete(5)); }. delete() no existe. assertThrows debe ir en assertAll. Falta encapsular la llamada en una lambda. assertThrows no permite usar excepciones personalizadas.

¿Qué valor falta en la siguiente configuración para que Jacoco aplique la regla al nivel de clase? <execution> <id>default-check</id> <goals> <goal>check</goal> </goals> <configuration> <rules> <rule> <!-- Falta aquí --> <limits> <limit> <counter>LINE</counter> <value>COVEREDRATIO</value> <minimum>0.80</minimum> </limit> </limits> </rule> </rules> </configuration> </execution>. <scope>CLASS</scope>. <group>UNIT</group>. <element>CLASS</element>. <level>CLASS</level>.

¿Qué valor de counter se usaría para validar que todas las decisiones lógicas están cubiertas?. INSTRUCTION. LINE. BRANCH. COMPLEXITY.

En la siguiente configuración, ¿qué condición se está verificando? <limit> <counter>COMPLEXITY</counter> <value>COVEREDRATIO</value> <minimum>0.70</minimum> </limit>. Que al menos el 70% de las líneas se han ejecutado. Que al menos el 70% de las ramas se han ejecutado. Que al menos el 70% de los caminos independientes (ciclomática) han sido cubiertos. Que el código tiene menos del 70% de complejidad.

¿Qué combinación de counter y value usarías para verificar que hay menos de 5 líneas no cubiertas por clase?. <counter>LINE</counter> <value>MISSEDRATIO</value> <maximum>5</maximum>. <counter>LINE</counter> <value>MISSEDCOUNT</value> <maximum>5</maximum>. <counter>LINE</counter> <value>COVEREDRATIO</value> <minimum>0.95</minimum>. <counter>LINE</counter> <value>TOTALCOUNT</value> <maximum>5</maximum>.