Decir lo obvio: No todos podemos trabajar en I+D. Pero aún podemos aprender algo de la jerga. Aquí hay una frase: marco de prueba de unidad JSL. ¿Qué es? ¿Cómo llegó a ser? ¿Y porque es importante?
Desmitifiquemos el marco de pruebas unitarias de JSL.
Gracias a Nicole Jones ( @Nicole_Jones ), Gerente 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 examen de la unidad es el proceso de validación para garantizar que las unidades funcionen como se espera. La frase marco de pruebas unitarias ha llegado a referirse al mecanismo utilizado para facilitar las pruebas unitarias automatizadas”.
Estadístico de investigación principal Joseph Morgan ( @Joseph Morgan ) presentó estos términos a JMP cuando comenzó a trabajar como probador estadístico en 2005. (Ahora trabaja en el grupo del DOE). La experiencia de Joseph es en ingeniería de software y ciencias de la computación, así como en matemáticas discretas y estadística.
"Él concibió todo el concepto, un marco de prueba central", dice la gerente sénior de ingeniería de prueba 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)
'Bebiendo 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 de JSL, "estamos usando 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 probar nuestro software porque tenemos este lenguaje JSL versátil", continúa Audrey. “Estiramos los límites de lo que JSL puede hacer para respaldar el marco. Eso es algo muy especial. Y el marco en sí sirve como una gran prueba de regresión para la compatibilidad con versiones anteriores de JSL.
"Si el personal de desarrollo cambia la forma en que funcionan las secuencias de comandos, el grupo de prueba lo encuentra primero porque somos el primer cliente del lenguaje JSL.
“Todas las empresas intentan usar la automatización, pero a menudo usan otras herramientas de terceros para hacerlo. No siempre tendrán el lujo de usar 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 de JSL se utiliza en todas las plataformas JMP. Por ejemplo, se puede usar 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 solo podemos usarlo para probar JSL en sí mismo, sino que también podemos usar el marco para probar todas las demás plataformas”, dice Audrey.
Nicole elabora:
“En el momento en que Joseph estaba desarrollando el marco, su enfoque 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 fuera extensible: el conjunto de pruebas de regresión incluye plataformas estadísticas y gráficas, funciona tanto en Macintosh como en Windows, prueba los comandos de la tabla de datos y las estructuras de los informes”.
Trabajando con 'una red de seguridad'
El marco se puede ejecutar manualmente: los evaluadores y los desarrolladores pueden iniciar, apuntar, hacer clic y ejecutar. Pero la automatización es clave para la mejora continua.
El marco se automatiza a través de Perforce (un repositorio de trabajo), donde vive el trabajo de los desarrolladores, donde se implementa el código. Los probadores de JMP escriben casos de prueba y los suben a 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 realizan: cada noche se ejecutan 2,4 millones de pruebas. Y eso sucede en todos los sistemas operativos (p. ej., Windows, Catalina, BigSur) tanto para JMP 17 como para JMP 16.2. El proceso para ejecutar las pruebas en una sola máquina toma de 6 a 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 de que ocurrió una falla.
"A veces nos gusta llamarlo una 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 pasar a otras cosas. Estamos tratando de probar lo nuevo y lo que viene y lo que se agrega al software”.
El flujo de trabajo del marco de prueba de JSL
Encontrar un error de Apple
Joseph comparte una anécdota temprana que consolidó el valor del marco de pruebas unitarias.
“Poco después de que la implementación inicial del marco de prueba de unidades JSL estuviera en funcionamiento, su valor se hizo 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 ayudar en esta transición, incluyó un emulador con MacOS conocido como Rosetta. Este emulador permitió que las aplicaciones PowerPC se ejecutaran en Intel Mac y, por lo tanto, Apple lo consideró una pieza clave del software.
“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 los ingenieros de Apple para explicar el problema, pero los ingenieros insistieron en que se trataba de un error de JMP. No fue hasta que Michael sugirió que escribiera una aplicación C++ muy simple que imitaba esencialmente 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 de Rosetta en Mac OS X 10.4.8.
¿Quién se beneficia?
“[El marco] se desarrolló pensando en los probadores, pero también ha demostrado ser útil para los desarrolladores”, dice Nicole. “Aprecio la capacidad de Joseph para crear un marco que pueda abordar las necesidades de muchos de nosotros”.
Los probadores ubicados en Cary y Beijing reparten funciones y monitorean ciertas áreas de JMP. Pero no importa de qué parte de JMP sean responsables de las pruebas, todos también están probando esencialmente el lenguaje de secuencias de comandos.
Audrey dice: “Cuanto más usamos JMP y JSL, pensamos en 'buenos para tener'. Aunque no somos nosotros los que implementamos las cosas, a veces somos los que preguntamos '¿puedes agregar esto o aquello?'”
Y la mejora constante, por supuesto, beneficia a los clientes.
“Nuestros usuarios avanzados de JSL pueden querer hacer algunas de las cosas que estamos haciendo. Nos impulsa a pensar cómo podemos escribir un guión de una manera más sólida”.
Muchas campanas y silbatos que se agregaron fueron colaboraciones colectivas del equipo de desarrollo, pruebas e ingeniería de lanzamiento.
Felicitaciones a los jugadores clave que han agregado funcionalidad a lo largo de los años:
Joseph Morgan @Joseph Morgan
melanie drake @Melanie_J_Drake
jim bork
xan gregg @xangregg
Michael Hecht @hecht_jmp
justin chilton @Justin_Chilton
Evan McCorkle @EvanMcCorkle
nick holmes @nickholmes13
Este es solo uno de los muchos ejemplos del ingenio, la colaboración y el compromiso de la división JMP con la mejora continua. Esperamos destacar más historias como esta. Comuníquese con Jessica Marquardt con ideas.
¿Quieres más información?
Tablero de pruebas de JMP
Este artículo del boletín de I+D de China escrito por la directora 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 de JSL para las ejecuciones nocturnas de las pruebas unitarias: Canalización de datos del marco JSL
Un artículo de Joseph Morgan: Unidad JSL: Pruebas JSL automatizadas
Orso, Alessandro y Gregg Rothermel. "Pruebas de software: un cuaderno de viaje de investigación (2000-2014)". 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 proporcionar antecedentes y orientación.
