TESTS PARA REPOSITORIOS SQLITE

• Módulo: PD4 - CEPY
• Unidad: UT3 — Persistencia con bases de datos
• Prerrequisitos: apuntes UT3-1, UT3-2, unittest básico, pathlib

---

1. Aislamiento en los tests de base de datos

Por qué los tests necesitan su propia base de datos

Un test de repositorio comprueba que las operaciones sobre la base de datos (guardar, obtener, etc.) se comportan correctamente. A diferencia de los tests de dominio — que trabajan con objetos en memoria —, estos tests leen y escriben en un fichero .db real.

El problema surge cuando varios tests comparten la misma base de datos: los datos que crea un test quedan visibles para el siguiente, y el resultado puede depender del orden de ejecución. Esto hace los tests frágiles e impredecibles.

La solución es que cada test trabaje sobre una base de datos nueva y vacía: creada justo antes de que el test empiece y eliminada al terminar. Para ello se usan los métodos setUp y tearDown de unittest.TestCase.

El fichero de test con Path

pathlib.Path gestiona la ruta del fichero de test y proporciona los métodos .exists() (comprobar que archivo existe) y .unlink() (eliminar archivo) que usaremos en el ciclo setUp/tearDown.

from pathlib import Path
import unittest

class TestRepositorioSQLite(unittest.TestCase):

    BD_TEST = Path("test_expendedora.db")

BD_TEST es un atributo de clase — todas las instancias del test comparten la misma ruta, pero cada test crea y elimina el fichero de nuevo.

Usa un nombre distinto al de la base de datos de producción (expendedora.db) para que los tests nunca modifiquen los datos reales.

Mala práctica: usar la BD de producción en los tests

## Incorrecto: los tests modifican la BD real y dejan datos basura
self.repo = RepositorioProductosSQLite("expendedora.db")

## Correcto
self.repo = RepositorioProductosSQLite(self.BD_TEST)

---

2. El ciclo setUp y tearDown

setUp — preparar la base de datos antes de cada test

setUp es el método de unittest.TestCase que se ejecuta automáticamente antes de cada método de test. Aquí creamos el esquema de tablas y el repositorio que usará el test.

def setUp(self):
    if self.BD_TEST.exists():
        self.BD_TEST.unlink()       ## estado limpio de partida

    conn = sqlite3.connect(self.BD_TEST)
    cursor = conn.cursor()
    cursor.execute("CREATE TABLE ...")  ## crear el esquema necesario
    conn.commit()
    conn.close()

    self.repo = MiRepositorio(self.BD_TEST)

sqlite3.connect() acepta objetos Path directamente — no hace falta convertir a str. El unlink() inicial garantiza un estado de partida limpio aunque el proceso anterior se interrumpiera sin llegar a tearDown.

tearDown — eliminar el fichero al terminar

tearDown se ejecuta automáticamente después de cada método de test, tanto si el test pasa como si falla. Su única responsabilidad es dejar el sistema como estaba antes del test.

def tearDown(self):
    if self.BD_TEST.exists():
        self.BD_TEST.unlink()

En Python 3.8+ se puede escribir self.BD_TEST.unlink(missing_ok=True) para omitir la comprobación de existencia previa. En versiones anteriores la comprobación con .exists() es obligatoria.

setUp y tearDown forman un ciclo simétrico: si setUp crea, tearDown destruye. Cada test recibe una base de datos vacía y la deja igual al terminar.

Mala práctica: no limpiar tras el test

## Incorrecto: los ficheros se acumulan y los tests se contaminan entre ejecuciones
def setUp(self):
    conn = sqlite3.connect(self.BD_TEST)
    ...
## (sin tearDown)

## Correcto
def setUp(self):
    if self.BD_TEST.exists():
        self.BD_TEST.unlink()
    ...

def tearDown(self):
    if self.BD_TEST.exists():
        self.BD_TEST.unlink()

---

3. Testar las operaciones del repositorio

Verificar que guardar() persiste los datos

El test comprueba el resultado observable: después de llamar a guardar(), los datos deben poderse recuperar con obtener().

def test_guardar_persiste_el_producto(self):
    self.repo.guardar(Item("A1", "Agua", 1.00, 10))
    item = self.repo.obtener("A1")
    self.assertEqual(item.nombre, "Agua")
    self.assertEqual(item.precio, 1.00)
    self.assertEqual(item.cantidad, 10)

Verificamos atributos individuales en lugar del objeto completo porque Item no tiene __eq__ definido. Comparar objetos enteros produciría siempre False.

Verificar que obtener() reconstruye el tipo correcto

El repositorio debe devolver un ItemConDescuento cuando el producto tiene entrada en descuentos, y un Item base cuando no la tiene.

def test_obtener_devuelve_item_con_descuento(self):
    self.repo.guardar(ItemConDescuento("D1", "Refresco", 2.50, 5, 20))
    item = self.repo.obtener("D1")
    self.assertIsInstance(item, ItemConDescuento)
    self.assertAlmostEqual(item.porcentaje_descuento, 20.0)

def test_obtener_devuelve_item_normal(self):
    self.repo.guardar(Item("A1", "Agua", 1.00, 10))
    item = self.repo.obtener("A1")
    self.assertIsInstance(item, Item)
    self.assertNotIsInstance(item, ItemConDescuento)

assertIsInstance comprueba el tipo del objeto, no solo sus atributos. Es el test adecuado cuando la lógica depende de que el objeto sea de una clase concreta.

El lab UT3-A3 guía la construcción del fichero tests/test_repositorio_sqlite.py completo, paso a paso, aplicando todos los patrones de esta sección.

---

4. Testar excepciones de dominio

assertRaises con excepciones propias

Los tests verifican que el repositorio lanza excepciones de dominio, no excepciones internas de sqlite3. El patrón es idéntico al que ya conoces con ValueError.

def test_obtener_codigo_inexistente_lanza_excepcion(self):
    with self.assertRaises(ProductoNoEncontradoError):
        self.repo.obtener("X9")

def test_guardar_duplicado_lanza_excepcion(self):
    self.repo.guardar(Item("A1", "Agua", 1.00, 10))
    with self.assertRaises(ProductoYaExisteError):
        self.repo.guardar(Item("A1", "Duplicado", 0.50, 3))

Testar ProductoYaExisteError en lugar de sqlite3.IntegrityError garantiza que el repositorio cumple su contrato: la capa de presentación nunca debería ver excepciones de SQLite.

Verificar el mensaje de la excepción

Si el mensaje de error aporta información útil al usuario, se puede comprobar con assertIn sobre el contexto del assertRaises:

def test_excepcion_incluye_el_codigo(self):
    with self.assertRaises(ProductoNoEncontradoError) as ctx:
        self.repo.obtener("X9")
    self.assertIn("X9", str(ctx.exception))

ctx.exception contiene el objeto excepción capturado. str() lo convierte a texto para poder buscar dentro del mensaje con assertIn.

Mala práctica: testar la excepción interna de SQLite

## Incorrecto: el test se acopla a la infraestructura — si cambias SQLite el test se rompe
with self.assertRaises(sqlite3.IntegrityError):
    self.repo.guardar(Item("A1", "Duplicado", 0.50, 3))

## Correcto: el test solo conoce excepciones de dominio
with self.assertRaises(ProductoYaExisteError):
    self.repo.guardar(Item("A1", "Duplicado", 0.50, 3))