En JUnit 5, `@BeforeEach` se ejecuta una sola vez antes de todos los tests de la clase.

Falso. Se ejecuta antes de cada test. Para una sola vez está `@BeforeAll`.

Por defecto, JUnit 5 crea una instancia nueva de la clase de test para cada método de test.

Verdadero. Es el ciclo de vida `PER_METHOD`. Así los tests no comparten estado a través de los campos.

Con `assertThatThrownBy(() -> ...)` de AssertJ puedes comprobar el tipo y el mensaje de la excepción.

Verdadero. Por ejemplo: `.isInstanceOf(IllegalArgumentException.class).hasMessageContaining("saldo")`.

Un `PreparedStatement` con parámetros `?` protege frente a la inyección SQL.

Verdadero. Los valores viajan separados de la sentencia y nunca se interpretan como SQL.

Concatenar en el SQL lo que escribe el usuario es seguro si después ejecutas la sentencia con un `PreparedStatement`.

Falso. Si el texto ya está concatenado, la inyección ya ha ocurrido. La protección viene de los parámetros `?`, no de la clase.

Con `setAutoCommit(false)`, los cambios no se confirman hasta que llamas a `commit()`.

Verdadero. Y si algo falla, `rollback()` los deshace todos. Es la base de una transacción manual en JDBC.

Abrir una conexión JDBC nueva para cada consulta es barato; un pool solo compensa en aplicaciones enormes.

Falso. Abrir una conexión implica red, autenticación y reserva de recursos en la base de datos. Un pool como HikariCP las reutiliza, y por eso Spring Boot lo trae por defecto.

La inyección por constructor permite declarar las dependencias como `final`.

Verdadero. El objeto nace completo y no puede quedar a medio configurar. Además, en los tests basta con hacer `new`.

Inversión de control significa que cada clase crea con `new` todas las dependencias que necesita.

Falso. Es justo lo contrario: alguien de fuera (el `main` o un contenedor como Spring) crea las dependencias y se las entrega.

Programar contra interfaces permite sustituir la implementación real por un doble de prueba en los tests.

Verdadero. La clase depende de `PaymentGateway`, no de `StripeGateway`, así que en el test puedes pasarle una implementación falsa.

Con `MockitoExtension`, un `when(...)` que el test no llega a usar hace fallar el test.

Verdadero. El modo estricto lanza `UnnecessaryStubbingException` para que los tests no acumulen preparación inútil ni escondan que el código siguió otro camino.

Un fake es un mock con más métodos configurados.

Falso. Un fake es una implementación que funciona de verdad pero de forma simplificada, como un repositorio en memoria. Un mock solo devuelve lo que le preparas y registra las llamadas.

`ArgumentCaptor` sirve para inspeccionar el objeto con el que se llamó a un mock.

Verdadero. Se usa dentro de `verify(...)` con `captor.capture()`, y después `captor.getValue()` devuelve el argumento para comprobarlo con AssertJ.

Mockear el `EntityManager` es la mejor forma de comprobar que una consulta JPQL es correcta.

Falso. Con un mock la consulta nunca se ejecuta, así que sus errores pasan desapercibidos. Las consultas se prueban contra una base de datos real con Testcontainers.

Quiz de la fase 2 Fase 2: De Vanilla a la Necesidad de Herramientas

¿Verdadero o falso?

14 afirmaciones sobre los días de esta fase. Responde cada una y lee la explicación: el fallo suele estar en un matiz.

0 de 14 respondidas
0 aciertos

En JUnit 5, @BeforeEach se ejecuta una sola vez antes de todos los tests de la clase.
Por defecto, JUnit 5 crea una instancia nueva de la clase de test para cada método de test.
Con assertThatThrownBy(() -> ...) de AssertJ puedes comprobar el tipo y el mensaje de la excepción.
Un PreparedStatement con parámetros ? protege frente a la inyección SQL.
Concatenar en el SQL lo que escribe el usuario es seguro si después ejecutas la sentencia con un PreparedStatement.
Con setAutoCommit(false), los cambios no se confirman hasta que llamas a commit().
Abrir una conexión JDBC nueva para cada consulta es barato; un pool solo compensa en aplicaciones enormes.
La inyección por constructor permite declarar las dependencias como final.
Inversión de control significa que cada clase crea con new todas las dependencias que necesita.
Programar contra interfaces permite sustituir la implementación real por un doble de prueba en los tests.
Con MockitoExtension, un when(...) que el test no llega a usar hace fallar el test.
Un fake es un mock con más métodos configurados.
ArgumentCaptor sirve para inspeccionar el objeto con el que se llamó a un mock.
Mockear el EntityManager es la mejor forma de comprobar que una consulta JPQL es correcta.