visual unitarias unit test studio que pruebas ejemplo atdd unit-testing testing scientific-computing

unit testing - unitarias - ¿Cómo probar el software científico?



unit test c# visual studio 2017 (4)

Acabo de ver un problema similar (google: "probar software científico") y encontré algunos artículos que pueden ser de interés. Estos cubren tanto los errores de codificación mundanos como los problemas más importantes de saber si el resultado es correcto (¿la profundidad del manto de la Tierra?)

http://http.icsi.berkeley.edu/ftp/pub/speech/papers/wikipapers/cox_harris_testing_numerical_software.pdf

http://www.cs.ua.edu/~SECSE09/Presentations/09_Hook.pdf (enlace roto; el nuevo enlace es http://www.se4science.org/workshops/secse09/Presentations/09_Hook.pdf )

http://www.associationforsoftwaretesting.org/?dl_name=DianeKellyRebeccaSanders_TheChallengeOfTestingScientificSoftware_paper.pdf

Pensé que la idea de las pruebas de mutación descritas en 09_Hook.pdf (ver también matmute.sourceforge.net) es particularmente interesante ya que imita los simples errores que todos cometemos. La parte más difícil es aprender a usar el análisis estadístico para los niveles de confianza, en lugar de las revisiones de códigos de paso único (hombre o máquina).

El problema no es nuevo. Estoy seguro de que tengo una copia original de "¿Qué tan preciso es el software científico?" por Hatton et al., octubre de 1994, que incluso entonces mostró cómo diferentes implementaciones de las mismas teorías (como algoritmos) divergieron bastante rápidamente (también se encuentra en la referencia 8 en el documento de Kelly & Sanders)

Estoy convencido de que las pruebas de software son muy importantes, especialmente en la ciencia. Sin embargo, en los últimos 6 años, nunca me he encontrado con ningún proyecto de software científico que se haya sometido a pruebas regulares (y la mayoría de ellos ni siquiera estaban controlados por versión).

Ahora me pregunto cómo lidiar con las pruebas de software para los códigos científicos (cálculos numéricos).

Desde mi punto de vista, las pruebas unitarias estándar a menudo pasan por alto el punto, ya que no hay un resultado exacto, por lo que usar assert(a == b) podría resultar un poco difícil debido a errores numéricos "normales".

Así que estoy deseando leer tus pensamientos sobre esto.



También estoy en la academia y he escrito programas de simulación de mecánica cuántica para ser ejecutados en nuestro clúster. Hice la misma observación con respecto a las pruebas o incluso el control de versiones. Era aún peor: en mi caso, estoy usando una biblioteca de C ++ para mis simulaciones y el código que obtuve de otros era código de espagueti puro, sin herencia, ni siquiera funciones.

Lo reescribí y también implementé algunas pruebas unitarias. Tienes razón en que tienes que lidiar con la precisión numérica, que puede ser diferente dependiendo de la arquitectura en la que estés ejecutando. Sin embargo, es posible realizar pruebas unitarias, siempre que tenga en cuenta estos errores de redondeo numérico. Su resultado no debe depender del redondeo de los valores numéricos, de lo contrario tendría un problema diferente con la robustez de su algoritmo.

Así que, para concluir, utilizo las pruebas unitarias para mis programas científicos, y realmente hace que uno se sienta más seguro con los resultados, especialmente con respecto a la publicación de los datos al final.


También estoy usando cpptest para su TEST_ASSERT_DELTA . Estoy escribiendo programas numéricos de alto rendimiento en electromagnética computacional y lo he estado utilizando felizmente en mis programas C ++.

Por lo general, pruebo el código científico de la misma manera que lo hago con cualquier otro tipo de código, con solo algunos retoques, a saber:

  • Siempre pruebo mis códigos numéricos para los casos que no tienen sentido físico y me aseguro de que el cálculo realmente se detenga antes de producir un resultado. Aprendí esto de la manera difícil: tenía una función que estaba calculando algunas respuestas de frecuencia, luego suministré una matriz construida con ellas a otra función como argumentos que eventualmente dieron a su respuesta un solo vector. La matriz podría haber sido de cualquier tamaño dependiendo de a cuántos terminales se aplicó la señal, pero mi función no fue verificar si el tamaño de la matriz era consistente con el número de terminales (2 terminales deberían haber significado una matriz de 2 x 2 xn); sin embargo, el código en sí mismo se envolvió para no depender de eso, no le importaba el tamaño de las matrices ya que solo tenía que hacer algunas operaciones de matriz básicas en ellas. Eventualmente, los resultados fueron perfectamente plausibles, bien dentro del rango esperado y, de hecho, parcialmente correctos: solo la mitad del vector de solución estaba distorsionada. Me tomó un tiempo calcularlo. Si sus datos parecen correctos, se ensamblan en una estructura de datos válida y los valores numéricos son buenos (por ejemplo, sin NaN o un número negativo de partículas) pero no tiene sentido físico, la función tiene que fallar con gracia.

  • Siempre pruebo las rutinas de E / S incluso si solo están leyendo un grupo de números separados por comas de un archivo de prueba. Cuando estás escribiendo un código que hace cálculos retorcidos, siempre es tentador saltar a la depuración de la parte del código que es tan pesada en matemáticas que necesitas una descarga de cafeína solo para entender los símbolos. Días después, se da cuenta de que también está agregando el valor ASCII de /n a su lista de puntos.

  • Al probar una relación matemática, siempre la pruebo "por el libro", y también aprendí esto con el ejemplo. He visto un código que debía comparar dos vectores, pero solo comprobó la igualdad de elementos y no comprobó la igualdad de longitud.