Inyección de dependencias

Inyección de dependencias suena grande, pero la idea es simple: en vez de que un objeto cree lo que necesita, se lo pasas desde fuera. Eso te deja cambiar esa pieza —por una falsa en tests, por otra implementación en producción— sin tocar el objeto. Es la base de un código testeable.

El problema: dependencias fijas

Si un modelo crea directamente su servicio de red, está atado a él: no puedes probarlo sin internet, ni cambiarlo:

@Observable
class Feed {
    private let servicio = ServicioReal()   // ❌ dependencia rígida
    func cargar() async { /* usa servicio */ }
}

La solución: depende de un protocolo

Define un contrato (protocolo) y haz que el modelo dependa de él, recibiéndolo desde fuera:

protocol ServicioFeed {
    func publicaciones() async throws -> [Publicacion]
}

@Observable
class Feed {
    private let servicio: ServicioFeed
    init(servicio: ServicioFeed) {          // ✅ inyectado
        self.servicio = servicio
    }
    func cargar() async { /* usa self.servicio */ }
}

Ahora Feed no sabe ni le importa qué servicio es, solo que cumple el contrato. En producción le pasas el real; en tests, uno falso.

Inyección por environment

Para dependencias transversales, combina lo del Nivel 3: inyecta un servicio en el environment y las vistas lo toman de ahí. En iOS moderno, con @Entry defines una clave de environment para tu dependencia y la lees con @Environment. Útil cuando muchas vistas comparten el mismo servicio sin pasarlo por parámetros.

Sustituir en tests

Aquí se cobra la inversión. En un test, le pasas una implementación falsa que devuelve datos controlados:

struct ServicioFalso: ServicioFeed {
    func publicaciones() async throws -> [Publicacion] {
        [Publicacion(id: 1, title: "Test", body: "…")]   // datos fijos
    }
}

// en el test:
let feed = Feed(servicio: ServicioFalso())
await feed.cargar()
// ahora compruebas el resultado, sin depender de internet