¿Existen buenas razones para que los trabajos académicos relacionados con la codificación no requieran pasar las pruebas de unidad / integración durante el proceso de arbitraje?

Por lo tanto, los costos son bastante obvios: escribir pruebas unitarias para el código que no está destinado a ser usado nuevamente requiere mucho tiempo y requiere habilidades que poseen muy pocos estudiantes de doctorado (y sus asesores y colaboradores).

¿Dónde está el beneficio?

Déjame darte un ejemplo específico de mi propio trabajo (Rountree SC 2007). El punto de ese documento fue transformar lo que se había visto como un problema de programación de enteros no escalables en un problema de programación lineal escalable que resultó en un límite más estricto. Como parte de ese trabajo, escribí mucho código C para interactuar con la biblioteca del solucionador glpk, mucho código R para la visualización de datos y modifiqué varios puntos de referencia (algunos de los cuales fueron escritos en FORTRAN). El resultado de todo esto fue un argumento empírico que coincidió con el argumento matemático: tengo razón, y es importante para los códigos del mundo real.

Ese código nunca fue pensado para ser usado nuevamente. En cambio, lo que aprendimos de ese documento condujo al desarrollo del sistema de tiempo de ejecución Adagio (Rountree ICS 2009), que tampoco estaba destinado a ser reutilizado. Las lecciones aprendidas de Adagio se están aplicando al sistema de tiempo de ejecución GeoPM de Intel, que es un software de nivel profesional escrito por programadores profesionales. Es una gran victoria y estoy muy orgulloso de ello. Esos documentos tardaron años en publicarse. Sinceramente, no veo cómo tomar un par de años para endurecer el código hubiera beneficiado a nadie.

En resumen: el código de investigación no está destinado a ser reutilizado, ni debería serlo.

Muchos artículos científicos se basan en un esfuerzo de codificación, por lo que tener un código abierto con resultados verificables permite verificar que los autores no están haciendo trampa, o simplemente están cometiendo un error.

Por otro lado, hacer que el código llegue a un punto en el que pueda instalarse y ejecutarse en un sistema arbitrario es mucho trabajo, por lo que los investigadores prefieren no esforzarse.

Dicho esto, hay una creciente comprensión de que los resultados de la investigación deben ser reproducibles.

http://stodden.net/icerm_report.pdf

Hay raros esfuerzos sistemáticos para lograr la reproducibilidad: las transacciones ACM (muy prestigiosas) en software matemático ahora tienen una pista de “resultados computacionales replicados”, donde puede enviar su trabajo con el software, y el árbitro probará que el software realmente puede instalarse y da los resultados según lo anunciado.

http://www.sandia.gov/~maherou/d

Por cierto, la afirmación “pasar las pruebas ya no es difícil” es demasiado optimista. Gran parte del software científico depende de paquetes externos, y los autores a menudo usan la última versión, por lo que instalar un paquete de investigación generalmente significa actualizar SWIG, actualizar su compilador a las últimas características de C ++ 17, actualizar las herramientas automáticas, … Y luego, muchos desarrolladores piensan que gcc es el único compilador que existe, y su software no se compilará con compiladores comerciales como Intel o PGI.