Probar lo que solo funciona instalado

Qué solo funciona instalado

Ocho cosas, y las ocho producen fallos que en desarrollo no aparecen. Es la mejor justificación posible para probar el artefacto final.

El ciclo rápido

Instalar a mano en cada iteración es insoportable y hace que la gente no lo pruebe. La respuesta es reducirlo a un comando:

El paso 4 es el que la gente se salta y es el que hace visible el problema del entorno: lanzar el binario instalado desde una terminal no reproduce el caso real.

La máquina limpia

Y hay un segundo nivel de prueba que hace falta menos a menudo y descubre otras cosas: una máquina donde tu aplicación nunca ha estado.

Descubre lo que tu equipo de desarrollo tiene y un usuario no:

• Herramientas instaladas que tú diste por hechas. Nivel 45.5.
• Certificados de desarrollo en el almacén de confianza.
• Directorios de datos de versiones anteriores, que hacen que la primera ejecución no sea la primera.
• Y permisos ya concedidos —accesibilidad, notificaciones, llavero— que en una máquina nueva se piden desde cero.

El último es el más valioso: la secuencia de permisos que ve un usuario nuevo es imposible de ver en tu máquina, donde los concediste hace meses.

Una máquina virtual limpia, restaurada a un punto conocido, resuelve esto y merece existir aunque solo se use antes de cada publicación.

Qué se puede automatizar

Menos de lo que uno querría, y algo:

• Que el paquete contiene lo que debe —acompañantes, iconos, la declaración de asociaciones— es una comprobación de ficheros. Nivel 46.4.
• Que la firma verifica es un comando.
• Que el binario arranca y responde a una opción de versión, también.
• Y que el instalador se ejecuta sin interacción, igualmente.

Lo que no se automatiza fácil es la interacción con el escritorio — el doble clic, el enlace, el atajo, los permisos. Eso es una lista de comprobación manual de diez minutos, y merece existir escrita.