Cada rama catch era código muerto en las pruebas. Una costura de fallas de 15 líneas resolvió eso, y luego una sola suite de pruebas sin anotar tumbó todo el runner.
Cinco fragmentos de ~700 líneas, instrucciones que también piden qué está bien hecho, y el paso de verificación que separó los errores reales de los plausibles.
Adoptar un linter en código que nunca tuvo uno, un hook de pre-commit sin depender de ningún framework, y tres cosas que hizo el runner de macOS que la documentación no mencionaba.
La API de compra es la parte fácil. Las costuras entre StoreKit 2, el aislamiento de Swift 6, y la observación de SwiftUI son donde se fue el tiempo.
Mini-reproductor para cuando MusicKit queda mudo en el simulador: un protocolo de dos métodos, un indicador con una mentira honesta, y un bug dejado adentro.
Cinco pruebas que reportaban un simple «Crash»: un helper prolijo dejó que el ModelContainer se liberara mientras el store conservaba su contexto. Un contexto es algo prestado.
El verificador de aislamiento basado en regiones me dice que reporte un bug, y el Task no estructurado, pasado de moda, resulta ser la herramienta correcta.
Construyendo el flujo de agregar a la biblioteca, descubrí que MusicKit da IDs distintos y sin relación a las copias de biblioteca y catálogo del mismo álbum.
Construir una pantalla de playlist agrupada por álbum antes de tener datos reales: detección de EP y una prueba que atrapó un fixture desactualizado.
Un protocolo, un servicio real y un mock que registra sus escrituras: hacer que el simulador vuelva a ser útil, más el percance con el worktree y la trampa del target recién nacido.
Página 4 de 5