Pruebas unitarias del SDDatabaseService en Swift Data

Contenido del curso

Introducción al Testing en iOS

1
Testing en Swift más allá del 100% de cobertura
01:44 min

Unit Testing con XCTest

Integration testing

UI Testing con SwiftUI y XCTest

Reporte y Optimización de Calidad

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:06

Pruebas unitarias del SDDatabaseService en Swift Data

Curso de Swift Unit Testing

Clase 9 de 15

Clase 9 / 15

Recursos

Aislar el servicio de base de datos y probarlo por separado te permite garantizar que cada acceso y función funcione correctamente, sin depender del ViewModel ni de otras capas. Aquí verás cómo configurar pruebas unitarias en Swift Data paso a paso, desde el setup inicial hasta validar que un registro realmente se guardó en la base.

¿Por qué aislar el servicio de base de datos en pruebas unitarias?

Cuando integras tu ViewModel con la base de datos, ya validaste que ambos hablan bien entre sí. Pero eso no te asegura que el servicio de base de datos, por sí solo, esté haciendo su trabajo correctamente en cada función.

Aislarlo te da control. Si una función falla, sabes exactamente dónde está el problema. Y si mañana cambias el ViewModel, tus pruebas del servicio siguen siendo válidas.

¿Qué es una prueba unitaria de servicio? Es una prueba que valida una sola unidad de código (en este caso, el servicio de base de datos) sin depender de otras capas como la vista o el ViewModel.

¿Cómo configurar el archivo de test para SDDatabaseService?

Dentro del target de test, crea un nuevo archivo desde template, elige Unit Test y nómbralo SDDatabaseServiceTest. Guárdalo en la misma carpeta que el resto de tus pruebas para mantener el orden.

Después, borra los casos de ejemplo que vienen por defecto y agrega el @testable import Gastify (con t minúscula). Así tu archivo de pruebas tiene acceso interno al servicio que vas a evaluar [00:33].

¿Qué hacer en el setup y teardown?

Los métodos setUp y tearDown preparan y limpian el entorno antes y después de cada prueba. Aquí necesitas:

Llamar a super.setUp() y super.tearDown() para mantener el comportamiento base.
Declarar una función privada auxiliar clearDatabase que limpie los registros.
Inicializar la variable databaseService como instancia del servicio que vas a probar.

Como la clase corre en el main actor, el setup usa una expectation y un Task que se ejecuta en el main actor. Dentro llamas a clearDatabase, cierras la expectation y haces el wait correspondiente [01:25].

¿Cómo probar la función para guardar un nuevo registro?

La primera función a evaluar es la que agrega un registro nuevo. La idea es simple: guardas un registro, validas que la función devuelva true, y después confirmas que efectivamente quedó en la base.

El flujo queda así:

Crear un registro random a partir de tu modelo Record.
Llamar a await databaseService.saveNewRecord(record) y guardar el resultado en una variable success.
Hacer XCTAssertTrue(success) para validar que la función reportó éxito.
Ejecutar un fetchRecords con el filtro de hoy para traer los registros guardados.
Hacer XCTAssertTrue(fetchRecords.contains { $0.id == record.id }) para confirmar que el registro existe en la base.

Este segundo assert es clave. Sin él, solo estarías confiando en que la función devolvió true, pero no en que realmente persistió el dato.

¿Por qué hacer dos asserts en una misma prueba? Porque el primero valida la respuesta de la función y el segundo valida el efecto real en la base de datos. Una función puede devolver true sin haber guardado nada.

¿Cómo validar la función de fetchRecords?

Para probar la función que trae los registros, primero necesitas garantizar que haya al menos uno guardado. Por eso reutilizas la función saveNewRecord que ya validaste en la prueba anterior.

El proceso es directo:

Creas un registro nuevo.
Llamas a saveNewRecord para guardarlo.
Ejecutas fetchRecords, que devuelve una lista.
Haces un XCTAssertGreaterThan(fetchRecords.count, 0) con un mensaje de error descriptivo por si falla.

Usar greaterThan en lugar de un valor exacto te da flexibilidad: la prueba pasa mientras haya al menos un registro, sin importar si quedaron rastros de pruebas anteriores [03:15].

¿Cómo correr y validar los tests en Xcode?

Ve a tu plan de pruebas y confirma que el nuevo servicio SDDatabaseServiceTest esté agregado y que ambos tests estén seleccionados. Después usa Command + U para correr todas las pruebas.

Xcode hará el build y ejecutará los tests. Cuando terminen, abre el reporte para ver el resultado. Si todos pasan en verde, tu implementación está funcionando como esperas.

¿Qué funciones del servicio te quedan por probar?

Con las dos pruebas anteriores ya tienes el patrón. Ahora puedes replicarlo para las funciones que faltan en el servicio:

Actualizar un registro existente: guarda un registro, modifícalo, y valida que los cambios persistan en la base.
Eliminar un registro existente: guarda un registro, elimínalo, y valida que ya no aparezca en fetchRecords.
Obtener los totales de la base de datos: inserta varios registros con valores conocidos y valida que la suma coincida.

Deja el encabezado de cada función vacío en tu archivo de pruebas para que tengas claro qué te falta. Implementa cada test siguiendo el mismo patrón: prepara los datos, ejecuta la función, valida con asserts tanto la respuesta como el efecto real.

¿Cómo te fue implementando los tests de actualizar, eliminar y obtener totales? Cuéntame en los comentarios qué assert usaste para validar cada caso.

Resumen

¿Por qué aislar el servicio de base de datos en pruebas unitarias?

Aislarlo te da control. Si una función falla, sabes exactamente dónde está el problema. Y si mañana cambias el ViewModel, tus pruebas del servicio siguen siendo válidas.

¿Qué es una prueba unitaria de servicio? Es una prueba que valida una sola unidad de código (en este caso, el servicio de base de datos) sin depender de otras capas como la vista o el ViewModel.

¿Cómo configurar el archivo de test para SDDatabaseService?

¿Qué hacer en el setup y teardown?

Los métodos setUp y tearDown preparan y limpian el entorno antes y después de cada prueba. Aquí necesitas:

Llamar a super.setUp() y super.tearDown() para mantener el comportamiento base.
Declarar una función privada auxiliar clearDatabase que limpie los registros.
Inicializar la variable databaseService como instancia del servicio que vas a probar.

¿Cómo probar la función para guardar un nuevo registro?

El flujo queda así:

Crear un registro random a partir de tu modelo Record.
Llamar a await databaseService.saveNewRecord(record) y guardar el resultado en una variable success.
Hacer XCTAssertTrue(success) para validar que la función reportó éxito.
Ejecutar un fetchRecords con el filtro de hoy para traer los registros guardados.
Hacer XCTAssertTrue(fetchRecords.contains { $0.id == record.id }) para confirmar que el registro existe en la base.

Este segundo assert es clave. Sin él, solo estarías confiando en que la función devolvió true, pero no en que realmente persistió el dato.

¿Por qué hacer dos asserts en una misma prueba? Porque el primero valida la respuesta de la función y el segundo valida el efecto real en la base de datos. Una función puede devolver true sin haber guardado nada.

¿Cómo validar la función de fetchRecords?

Para probar la función que trae los registros, primero necesitas garantizar que haya al menos uno guardado. Por eso reutilizas la función saveNewRecord que ya validaste en la prueba anterior.

El proceso es directo:

Creas un registro nuevo.
Llamas a saveNewRecord para guardarlo.
Ejecutas fetchRecords, que devuelve una lista.
Haces un XCTAssertGreaterThan(fetchRecords.count, 0) con un mensaje de error descriptivo por si falla.

Usar greaterThan en lugar de un valor exacto te da flexibilidad: la prueba pasa mientras haya al menos un registro, sin importar si quedaron rastros de pruebas anteriores [03:15].

¿Cómo correr y validar los tests en Xcode?

Ve a tu plan de pruebas y confirma que el nuevo servicio SDDatabaseServiceTest esté agregado y que ambos tests estén seleccionados. Después usa Command + U para correr todas las pruebas.

Xcode hará el build y ejecutará los tests. Cuando terminen, abre el reporte para ver el resultado. Si todos pasan en verde, tu implementación está funcionando como esperas.

¿Qué funciones del servicio te quedan por probar?

Con las dos pruebas anteriores ya tienes el patrón. Ahora puedes replicarlo para las funciones que faltan en el servicio:

Actualizar un registro existente: guarda un registro, modifícalo, y valida que los cambios persistan en la base.
Eliminar un registro existente: guarda un registro, elimínalo, y valida que ya no aparezca en fetchRecords.
Obtener los totales de la base de datos: inserta varios registros con valores conocidos y valida que la suma coincida.

¿Cómo te fue implementando los tests de actualizar, eliminar y obtener totales? Cuéntame en los comentarios qué assert usaste para validar cada caso.

Diego Gerardo Corbinaud Castañeda

Hace un año

func testUpdateRecord_ShouldModifyExistingRecord() async {

let record = Record(id: UUID().uuidString, title: "Test Record 1", date: Date(), type: .income, amount: 100.0)

_ = await databaseService.saveNewRecord(record)

let recordUpdated = Record(id: record.id, title: "Updated Record", date: Date(), type: .income, amount: 200.0)

let success = await databaseService.updateRecord(recordUpdated)

XCTAssertTrue(success)

let fetchRecords = await databaseService.fetchRecords(filter: .today)

XCTAssertEqual(fetchRecords.first!.title, recordUpdated.title)

}

func testDeleteRecord_ShouldRemoveRecordFromDatabase() async {

let record = Record(id: UUID().uuidString, title: "Test Record 1", date: Date(), type: .income, amount: 100.0)

_ = await databaseService.saveNewRecord(record)

let success = await databaseService.deleteRecord(record)

XCTAssertTrue(success)

let fetchRecords = await databaseService.fetchRecords(filter: .today)

XCTAssertEqual(fetchRecords.count, 0)

}

func testGetTotals_ShouldReturnCorrectSum() async {

let record1 = Record(id: UUID().uuidString, title: "Test Record 1", date: Date(), type: .income, amount: 100.0)

let record2 = Record(id: UUID().uuidString, title: "Test Record 2", date: Date(), type: .income, amount: 200.0)

let record3 = Record(id: UUID().uuidString, title: "Test Record 3", date: Date(), type: .outcome, amount: 126.0)

let record4 = Record(id: UUID().uuidString, title: "Test Record 4", date: Date(), type: .outcome, amount: 54.0)

_ = await databaseService.saveNewRecord(record1)

_ = await databaseService.saveNewRecord(record2)

_ = await databaseService.saveNewRecord(record3)

_ = await databaseService.saveNewRecord(record4)

let total = await databaseService.getTotals()

XCTAssertEqual(total.income, 300.0)

XCTAssertEqual(total.outcome, 180.0)

}

Introducción al Testing en iOS

Testing en Swift más allá del 100% de cobertura

Unit Testing con XCTest

Pruebas Unitarias con XC Test en Desarrollo de Apps SWIFT

Tests asíncronos con XCTest en Swift

Pruebas Unitarias para View Models en Swift

Testing de Software: Estrategias y Configuración en Xcode

Mocks y stubs para unit tests en Swift

Pruebas Unitarias en Home View Model: Implementación y Validación

Integration testing

Pruebas de integración con SwiftData y ViewModel

Pruebas unitarias del SDDatabaseService en Swift Data

UI Testing con SwiftUI y XCTest

Qué es UI Testing en iOS con XCTest

Preparación de Proyectos para UI Testing en iOS

Pruebas de Interfaz de Usuario: Validación y Simulación de Eventos

Pruebas de navegación entre pantallas con XCUITest

Reporte y Optimización de Calidad

Code coverage en Xcode paso a paso

Estrategias Avanzadas de Testing en Desarrollo de Software

Pruebas unitarias del SDDatabaseService en Swift Data

Progreso del curso

Introducción al Testing en iOS

Unit Testing con XCTest

Integration testing

UI Testing con SwiftUI y XCTest

Reporte y Optimización de Calidad

Recursos

Recursos