Las pruebas automáticas ejercitan el comportamiento de la librería. La exigencia de cobertura es de al menos 95,01 % por separado en statements, branches, functions y lines: instrucciones ejecutadas, caminos de decisión, funciones y líneas de código.
La cobertura no es una nota de accesibilidad ni una garantía para el tema de tu aplicación. La compilación, los imports públicos y las interacciones tras el renderizado en servidor se comprueban por separado. Tu aplicación necesita también las pruebas de tareas descritas a continuación.
Compila la aplicación y verifica sus tareas reales: modelos editables, validación, estados deshabilitado y de carga, navegación por teclado y restauración de foco. Repite en los navegadores admitidos y layouts estrechos y amplios representativos.
En aplicaciones renderizadas en servidor, revisa el HTML inicial útil y utiliza la interfaz después de hidratar. Incluye rutas traducidas, metadatos de título y descripción y errores de consola en la revisión de publicación.
Importa cada componente desde la ruta pública que documenta su ficha, como @neural-ui/core/button. Evita rutas al código fuente o a carpetas privadas de la librería: esos archivos no son una API admitida y pueden cambiar sin un contrato público.
Un bundle es el JavaScript que tu aplicación envía al navegador. Importar solo los componentes y las definiciones de iconos que utilizas permite al build eliminar código sin uso. Mide la compilación de producción de tu propia aplicación; el tamaño de la librería por sí solo no predice cuánto descarga una página.
Comprueba también la compilación estricta de TypeScript. Que el build del navegador funcione no demuestra por sí solo que todas las declaraciones de tipos publicadas se resuelvan correctamente en todas las herramientas admitidas.
