Dicho lo obvio: no todos podemos trabajar en I+D. Pero todavía podemos aprender algo de la jerga. Aquí hay una frase: marco de prueba unitaria JSL. ¿Qué es? ¿Cómo surgió? ¿Y porque es importante?
Desmitifiquemos el marco de pruebas unitarias de JSL.
Gracias a Nicole Jones ( @Nicole_Jones ), directora sénior de pruebas de análisis avanzado, por esta explicación:
“El término unidad se refiere al componente comprobable más pequeño de un producto de software y la frase prueba unitaria es el proceso de validación para garantizar que las unidades funcionen como se espera. La frase marco de pruebas unitarias ha pasado a referirse al mecanismo utilizado para facilitar las pruebas unitarias automatizadas”.
El investigador principal en estadística, Joseph Morgan ( @joseph_morgan ), introdujo estos términos en JMP cuando comenzó a trabajar como evaluador estadístico en 2005 (ahora trabaja en el grupo DOE). La experiencia de Joseph es en ingeniería de software e informática, así como en matemáticas discretas. y estadísticas.
"Él concibió todo el concepto, un marco de pruebas central", dice la directora sénior de ingeniería de pruebas, Audrey Shull ( @Audrey_Shull ). "Tiene muchas grandes ideas y esta fue una de ellas".
"Una vez que se familiarizó con JMP y JSL, pudo desarrollar el marco de pruebas unitarias de JSL, teniendo en cuenta la naturaleza estadística del software", dice Nicole.
Joseph Morgan explica (4:38)
'Beber nuestro propio champán'
Un marco de pruebas unitarias se puede escribir en otros lenguajes, pero ¿qué mejor herramienta que nuestro propio JSL?
Con el marco de pruebas unitarias JSL, "estamos utilizando JMP para probar JMP", explica Audrey. En otras palabras, estamos "bebiendo nuestro propio champán". Y eso no es posible con todas las herramientas.
"Podemos usar nuestro software para probarlo porque tenemos este lenguaje JSL versátil", continúa Audrey. "Ampliamos los límites de lo que JSL puede hacer para respaldar el marco. Eso es algo bastante especial. Y el marco en sí sirve como un Gran prueba de regresión para la compatibilidad con versiones anteriores de JSL.
"Si el personal de desarrollo cambia la forma en que funcionan los scripts, el grupo de prueba lo encuentra primero porque somos el primer cliente del lenguaje JSL.
“Todas las empresas intentan utilizar la automatización, pero a menudo utilizan otras herramientas de terceros para hacerlo. No siempre tendrán el lujo de utilizar su propio software".
Un marco extensible
A screenshot of the original dialog. Una captura de pantalla del diálogo original. El marco de pruebas unitarias JSL se utiliza en todas las plataformas JMP. Por ejemplo, se puede utilizar para probar la funcionalidad de arrastrar y soltar en Graph Builder. O los menús del triángulo rojo. O cualquier unidad de código en la plataforma de Distribución.
"No sólo podemos usarlo para probar JSL en sí, sino que también podemos usar el marco para probar todas las demás plataformas", dice Audrey.
Nicole explica:
“En el momento en que Joseph estaba desarrollando el marco, su objetivo principal era encontrar una manera de crear un conjunto de pruebas de regresión para las plataformas estadísticas en JMP. Sin embargo, pudo crear un marco que era extensible: el conjunto de pruebas de regresión incluye plataformas de estadísticas y de gráficos, funciona tanto en Macintosh como en Windows, prueba comandos de tablas de datos y estructuras de informes”.
Trabajar con 'una red de seguridad'
El marco se puede ejecutar manualmente: los evaluadores y desarrolladores pueden iniciarlo, apuntar y hacer clic y ejecutar. Pero la automatización es clave para la mejora continua.
El marco está automatizado a través de Perforce (un repositorio de trabajo), donde reside el trabajo de los desarrolladores, donde se implementa el código. Los evaluadores de JMP escriben casos de prueba y los cargan en una sección dedicada en Perforce.
Screenshot of the testing dialog as it looks today.Captura de pantalla del cuadro de diálogo de prueba tal como se ve hoy.
Un proceso automatizado nocturno, ejecutado por el desarrollador principal de sistemas Jim Borek, toma todas las pruebas cargadas ese día, toma todo el código enviado ese día, ejecuta los casos de prueba en el código actualizado y notifica al equipo cuando algo falla. Jim es fundamental para automatizar este proceso y mantener las máquinas.
Audrey describió la enormidad de las pruebas que se llevan a cabo: cada noche se ejecutan 2,4 millones de pruebas. Y eso está sucediendo en todos los sistemas operativos (por ejemplo, Windows, Catalina, BigSur) tanto para JMP 17 como para JMP 16.2. El proceso para ejecutar las pruebas en una sola máquina demora entre 6 y 10 horas, dependiendo de qué tan rápido vayan las máquinas.
"Ese es el conjunto de pruebas de regresión; sin este marco, tendríamos que probar estas cosas todos los días para ver si fallan o no", dice Audrey. “No puede ser manual. El conjunto de pruebas está automatizado para que el sistema nos avise que ocurrió una falla.
"A veces nos gusta llamarlo red de seguridad. Sé que funcionó la última vez que lo probé, escribí un caso de prueba y, si falla, el sistema me avisa. Puedo seguir adelante con otras cosas. Estamos tratando de Pruebe las novedades que se avecinan y las que se agregan al software”.
El flujo de trabajo del marco de prueba JSL
Encontrar un error de Apple
Joseph comparte una de las primeras anécdotas que consolidó el valor del marco de pruebas unitarias.
“Poco después de que la implementación inicial del marco de pruebas unitarias JSL estuviera en funcionamiento, su valor se hizo dramáticamente evidente de una manera bastante inusual. Curiosamente, no fue una regresión de JMP lo que detectó, sino que fue clave para aislar un error bastante grave en MacOS.
“A principios de 2006, Apple comenzó la transición de la línea Macintosh de CPU PowerPC a CPU Intel y, para facilitar esta transición, incluyó un emulador con MacOS conocido como Rosetta. Este emulador permitía ejecutar aplicaciones PowerPC en Mac Intel y, por lo tanto, Apple lo consideraba una pieza de software clave.
“Resulta que hubo un error en el emulador de Rosetta que provocó varias anomalías inusuales en el comportamiento de JMP. Con el marco de pruebas unitarias, pude aislar el problema de un error en la implementación de la función de raíz cuadrada en Rosetta ( ver Defecto S0351925 ).
“Michael Hecht y yo tuvimos varias conferencias telefónicas con ingenieros de Apple para explicarles el problema, pero los ingenieros insistieron en que se trataba de un error de JMP. No fue hasta que Michael me sugirió que escribiera una aplicación C++ muy simple que esencialmente imitaba una de las pruebas unitarias que mostraban el error que Apple se convenció de que el problema era un error de Rosetta. Un año después, en marzo de 2007, Apple lanzó una solución para el error Rosetta en Mac OS X 10.4.8”.
¿Quién se beneficia?
"[El marco] se desarrolló pensando en los evaluadores, pero ha demostrado ser útil también para los desarrolladores", dice Nicole. "Aprecio la capacidad de Joseph para crear un marco que pueda abordar las necesidades de muchos de nosotros".
Los evaluadores ubicados en Cary y Beijing se reparten funciones y monitorean ciertas áreas de JMP. Pero no importa qué parte de JMP sean responsables de probar, básicamente todos también están probando el lenguaje de secuencias de comandos.
Audrey dice: “Cuanto más usamos JMP y JSL, pensamos en 'algo bueno para tener'. Aunque no somos nosotros los que implementamos las cosas, a veces somos nosotros los que preguntamos '¿podrías agregar esto o aquello?'”
Y la mejora constante, por supuesto, beneficia a los clientes.
“Es posible que nuestros usuarios avanzados de JSL quieran hacer algunas de las cosas que estamos haciendo. Nos lleva a pensar cómo podemos escribir guiones de una manera más sólida”.
Muchas características que se han agregado provienen del equipo de desarrollo, pruebas y de ingeniería de lanzamiento.
Felicitaciones a los jugadores clave que han agregado funcionalidad a lo largo de los años:
José Morgan @joseph_morgan
Melanie Drake @Melanie_J_Drake
Jim Borek
Xan Gregg @XanGregg
Michael Hecht @hecht_jmp
Justin Chilton @Justin_Chilton
Evan McCorkle @EvanMcCorkle
Nick Holmes @nickholmes13
Este es sólo uno de los muchos ejemplos del ingenio, la colaboración y el compromiso de la división JMP con la mejora continua. Esperamos resaltar más historias como ésta. Comuníquese con Jessica Marquardt con ideas.
¿Quieres más información?
Panel de pruebas JMP
Este artículo del boletín de investigación y desarrollo de China escrito por la gerente de ingeniería de pruebas Nala Sun ( @Nala ) sirvió de inspiración para esta publicación: Marco de automatización de pruebas unitarias JSL
Así es como se generan, procesan y utilizan los resultados de las pruebas unitarias JSL para las ejecuciones de pruebas unitarias nocturnas: JSL Framework Data Pipeline
Un artículo de Joseph Morgan: Unidad JSL: Pruebas JSL automatizadas
Orso, Alessandro y Gregg Rothermel. "Pruebas de software: un diario de viaje de investigación (2000-2014)". El futuro de los procedimientos de ingeniería de software. 2014. 117-132.
Página profesional de Alex Orso: https://www.cc.gatech.edu/home/orso/
Y gracias a @shannon_conners por brindarnos antecedentes y orientación.
