Testear la lógica: modelos, repositorios y estado

Una prueba de lógica que resulta difícil de escribir casi nunca revela un problema de pruebas: revela que el código bajo examen adquiere sus dependencias en lugar de recibirlas. Un modelo que construye su propio cliente de red, lee la hora del reloj del sistema y guarda en el almacén compartido no es un objeto difícil de probar, es un objeto que no tiene entradas, y sin entradas no hay función, y sin función no hay nada que verificar. Testear la lógica consiste por tanto en un trabajo previo de diseño: hacer explícito lo que estaba implícito hasta que el comportamiento del sujeto quede determinado por argumentos que la prueba controla. El resto es sintaxis.

La frontera del sujeto es un protocolo estrecho

El primer gesto es separar la decisión de la ejecución. La lógica interesante de una app casi siempre es una función del estado y de unos datos hacia un nuevo estado; todo lo demás es fontanería que se debe poder sustituir.

// La frontera: describe lo que el modelo NECESITA, no lo que el servicio SABE hacer.
protocol RepositorioTareas: Sendable {
    func cargar() async throws -> [Tarea]
    func guardar(_ tarea: Tarea) async throws
}

@Observable @MainActor
final class ListaTareasModel {
    enum Estado: Equatable { case inactivo, cargando, listo, fallo(String) }
    private(set) var tareas: [Tarea] = []
    private(set) var estado: Estado = .inactivo
    private let repositorio: any RepositorioTareas
    init(repositorio: any RepositorioTareas) { self.repositorio = repositorio }

    func cargar() async {
        estado = .cargando
        do {
            tareas = try await repositorio.cargar()
            estado = .listo
        } catch {
            estado = .fallo(String(describing: error))
        }
    }
}

El protocolo debe describir la necesidad del consumidor, no la capacidad del proveedor. Un protocolo con dieciocho métodos porque el servicio real tiene dieciocho obliga a cada doble a implementarlos todos y convierte cada cambio en el servicio en un cambio en todas las pruebas. Dos métodos que el modelo usa de verdad producen dobles de cinco líneas y desacoplan el ritmo de cambio de las dos capas. Esa es también la diferencia entre inyectar por constructor y leer un contenedor global desde dentro: lo primero hace la dependencia visible en la firma y por tanto sustituible en cada prueba; lo segundo la esconde y obliga a mutar estado compartido entre casos, que es la vía más rápida a una suite dependiente del orden. Conviene además centralizar la construcción del sujeto en una función hacerSut por suite, que devuelva también los dobles que la prueba vaya a interrogar: así una dependencia nueva no obliga a tocar treinta pruebas, y si esa función acaba necesitando diez parámetros, la señal no va sobre las pruebas sino sobre un sujeto con demasiadas responsabilidades.

Falso, stub y espía: qué afirma cada uno

Los dobles no son intercambiables, y elegir mal produce pruebas que se rompen sin que nada esté roto. La distinción práctica es qué papel juega el doble en la afirmación final.

final class RepositorioFalso: RepositorioTareas, @unchecked Sendable {
    var resultado: Result<[Tarea], Error> = .success([])
    private(set) var guardadas: [Tarea] = []          // parte de espía
    private(set) var vecesCargado = 0
    func cargar() async throws -> [Tarea] { vecesCargado += 1; return try resultado.get() }
    func guardar(_ tarea: Tarea) async throws { guardadas.append(tarea) }
}

@Test @MainActor func elFalloDeCargaDejaEstadoDeFallo() async {
    let repo = RepositorioFalso()
    repo.resultado = .failure(ErrorRed.sinConexion)
    let sut = ListaTareasModel(repositorio: repo)

    await sut.cargar()

    #expect(sut.tareas.isEmpty)                       // no hay datos parciales
    #expect(sut.estado == .fallo(String(describing: ErrorRed.sinConexion)))
}

La regla que ahorra más dolor a medio plazo es afirmar sobre el estado resultante siempre que sea posible, y recurrir al espía solo cuando el efecto no deja huella en el estado. Comprobar que el modelo terminó en fallo sobrevive a cualquier reorganización interna; comprobar que llamó dos veces a cargar fija un detalle de implementación que quizá mañana sea uno o tres sin que el comportamiento cambie.

El tiempo como parámetro, no como circunstancia

Todo lo que en el código dice “espera”, “reintenta”, “expira” o “agrupa” es lógica de negocio disfrazada de tiempo, y es exactamente donde viven los defectos difíciles. Dormir el hilo en la prueba es la solución equivocada: multiplica la duración de la suite y sustituye determinismo por probabilidad.

struct ClienteConReintento<C: Clock> where C.Duration == Duration {
    let reloj: C                       // producción: ContinuousClock
    let base: any RepositorioTareas
    let intentos: Int

    func cargar() async throws -> [Tarea] {
        var espera = Duration.milliseconds(200)
        for intento in 1...intentos {
            do { return try await base.cargar() } catch {
                guard intento < intentos else { throw error }
                try await reloj.sleep(for: espera)   // el reloj decide, no el sistema
                espera *= 2                          // retroceso exponencial
            }
        }
        throw ErrorRed.sinConexion
    }
}

Al declarar la dependencia como un Clock genérico, producción recibe ContinuousClock y la prueba recibe un reloj de prueba que avanza cuando ella lo ordena. La suite pasa a comprobar la propiedad interesante —que hubo tres intentos y que la espera se duplicó— en microsegundos y sin ninguna condición de carrera. El mismo patrón cubre el antirrebote de un buscador, la caducidad de una credencial y el temporizador de una cuenta atrás. Y la lección general aplica a las otras dos fuentes de indeterminismo: el generador de números aleatorios y el generador de identificadores también deben ser parámetros, o la prueba tendrá que afirmar sobre valores que no puede predecir.

flowchart LR
sut[Sujeto bajo prueba] --> r[Reloj inyectado]
sut --> rep[Repositorio inyectado]
sut --> id[Generador de identificadores inyectado]
r --> t[Prueba: reloj que avanza cuando ella lo ordena]
rep --> t2[Prueba: falso en memoria o stub programado]
id --> t3[Prueba: secuencia predecible]
t --> d[Salidas determinadas por las entradas]
t2 --> d
t3 --> d

La red: interceptar en el borde correcto

Cuando el sujeto es el propio cliente de red —el que construye la petición y decodifica la respuesta— sustituir el protocolo entero no sirve, porque justo eso es lo que hay que probar. El punto de intercepción correcto está por debajo, en la capa de transporte.

final class ProtocoloFalso: URLProtocol {
    nonisolated(unsafe) static var responder: ((URLRequest) -> (HTTPURLResponse, Data))!
    override class func canInit(with peticion: URLRequest) -> Bool { true }
    override class func canonicalRequest(for p: URLRequest) -> URLRequest { p }
    override func stopLoading() {}

    override func startLoading() {
        let (respuesta, datos) = Self.responder(request)
        client?.urlProtocol(self, didReceive: respuesta, cacheStoragePolicy: .notAllowed)
        client?.urlProtocol(self, didLoad: datos)
        client?.urlProtocolDidFinishLoading(self)
    }
}

Con ese interceptor registrado en una configuración de sesión efímera, la prueba controla el código de estado, las cabeceras y el cuerpo exactos, y puede por tanto fijar las tres cosas que de verdad importan en esa capa: que la petición se construye con el verbo, la ruta y la autorización correctos; que una respuesta bien formada se decodifica en el modelo esperado; y que un cuerpo malformado o un código de error se traducen en el error de dominio que la interfaz sabe mostrar. Guardar cargas reales como recursos fijos y decodificarlas es, además, la prueba más barata que existe contra el cambio silencioso de un contrato ajeno.