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

> 14 afirmaciones de verdadero o falso, con la respuesta explicada, sobre los días de esta fase del plan JavaMastery.

Versión interactiva: https://aprende-java.webs-economicas.es/quiz/fase-2/

## Afirmaciones

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

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

**Para recordarlo:** `Each` = antes de cada test. `All` = una vez por clase, y el método es `static`.

Se estudia en el [día 8: Testing Profesional en Java Puro: JUnit 5 y AssertJ](https://aprende-java.webs-economicas.es/dias/junit-5-assertj.md).

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

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

**Para recordarlo:** Cada test empieza con un objeto nuevo: no cuentes con lo que dejó el anterior.

Se estudia en el [día 8: Testing Profesional en Java Puro: JUnit 5 y AssertJ](https://aprende-java.webs-economicas.es/dias/junit-5-assertj.md).

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

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

**Para recordarlo:** Comprueba tipo y mensaje: un test que solo mira el tipo puede pasar por el motivo equivocado.

Se estudia en el [día 8: Testing Profesional en Java Puro: JUnit 5 y AssertJ](https://aprende-java.webs-economicas.es/dias/junit-5-assertj.md).

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

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

**Para recordarlo:** Los datos del usuario siempre como parámetro `?`, nunca dentro del texto SQL.

Se estudia en el [día 9: Acceso a Datos Artesanal con JDBC: El Dolor del SQL Manual](https://aprende-java.webs-economicas.es/dias/jdbc-sql-manual.md).

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

**Respuesta:** 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.

**Para recordarlo:** La protección está en los `?`, no en el nombre de la clase. Si concatenas, ya es tarde.

Se estudia en el [día 9: Acceso a Datos Artesanal con JDBC: El Dolor del SQL Manual](https://aprende-java.webs-economicas.es/dias/jdbc-sql-manual.md).

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

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

**Para recordarlo:** Patrón: `setAutoCommit(false)`, el trabajo, `commit()`, y `rollback()` en el `catch`.

Se estudia en el [día 9: Acceso a Datos Artesanal con JDBC: El Dolor del SQL Manual](https://aprende-java.webs-economicas.es/dias/jdbc-sql-manual.md).

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

**Respuesta:** 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.

**Para recordarlo:** Las conexiones se piden prestadas al pool y se devuelven; no se crean cada vez.

Se estudia en el [día 9: Acceso a Datos Artesanal con JDBC: El Dolor del SQL Manual](https://aprende-java.webs-economicas.es/dias/jdbc-sql-manual.md).

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

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

**Para recordarlo:** Dependencias por constructor y `final`: el objeto nace completo y ya no cambia.

Se estudia en el [día 10: Inyección de Dependencias Manual: El Nacimiento de Spring](https://aprende-java.webs-economicas.es/dias/inyeccion-de-dependencias-manual.md).

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

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

**Para recordarlo:** IoC = «no me llames, ya te llamo yo»: la clase recibe sus dependencias, no las fabrica.

Se estudia en el [día 10: Inyección de Dependencias Manual: El Nacimiento de Spring](https://aprende-java.webs-economicas.es/dias/inyeccion-de-dependencias-manual.md).

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

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

**Para recordarlo:** Depende de la interfaz y podrás cambiar la implementación sin tocar la clase, también en los tests.

Se estudia en el [día 10: Inyección de Dependencias Manual: El Nacimiento de Spring](https://aprende-java.webs-economicas.es/dias/inyeccion-de-dependencias-manual.md).

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

**Respuesta:** 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.

**Para recordarlo:** Si sobra un stub, bórralo; si el código no lo usa, averigua por qué.

Se estudia en el [día 11: Mockito y Dobles de Prueba: Tests Unitarios Aislados](https://aprende-java.webs-economicas.es/dias/mockito-dobles-de-prueba.md).

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

**Respuesta:** 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.

**Para recordarlo:** Fake = funciona (en memoria). Mock = responde lo que le dices y apunta las llamadas.

Se estudia en el [día 11: Mockito y Dobles de Prueba: Tests Unitarios Aislados](https://aprende-java.webs-economicas.es/dias/mockito-dobles-de-prueba.md).

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

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

**Para recordarlo:** Para comprobar un objeto construido dentro del método: `ArgumentCaptor` + AssertJ.

Se estudia en el [día 11: Mockito y Dobles de Prueba: Tests Unitarios Aislados](https://aprende-java.webs-economicas.es/dias/mockito-dobles-de-prueba.md).

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

**Respuesta:** 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.

**Para recordarlo:** No mockees lo que no es tuyo: la base de datos se prueba con Testcontainers.

Se estudia en el [día 11: Mockito y Dobles de Prueba: Tests Unitarios Aislados](https://aprende-java.webs-economicas.es/dias/mockito-dobles-de-prueba.md).