SQLite afirma tener 679 veces más código de prueba que la producción uno. http://www.sqlite.org/testing.htmlcódigo de prueba SQLite a código de producción proporción
¿Alguien sabe cómo es posible? ¿Generan algún código de prueba automáticamente? ¿Cuáles son las partes principales de estos "45678.3 KSLOC" del código de prueba?
Es presumiblemente posible si los desarrolladores pasaron 679 veces más tiempo escribiendo el código de prueba mientras escribían el código de producción. Solo piense: si hubieran optado por 339 veces más código de prueba, podrían haber tenido dos motores de base de datos completos, cada uno con una cantidad ridícula de cobertura de prueba.
Una vez observé a un compañero desarrollador tratar de aplacar a un cliente furioso acerca de las fechas límite deslizadas al informarle que había escrito 5 veces más código de prueba que código de producción. El cliente fue no aplacado, si se puede imaginar. Al menos no creo que la cobertura 5X sea extrema.
Probablemente haya más personas escribiendo código de prueba que código de producción. Por ejemplo, el artículo describe su política en las pruebas de regresión: no tiene que entender el código SQLite para escribir una prueba de regresión para un error que acaba de encontrar e informar (aunque alguien tiene que encajarlo en el arnés de prueba). Aún así, 45 MLOC me parece una cantidad increíble: incluso si todo está en repositorios y, por lo tanto, "no autogenerado", gran parte de él podría haber sido generado en máquina, en primer lugar, si solo fuera por las macros de emacs ... –
Sospecho que muchas de las pruebas (especialmente en TH3) fueron contribuidas por los fabricantes de teléfonos móviles. Tienen un gran interés en * muy * pruebas exhaustivas del motor de base de datos que envían ... –
Además, quita y reemplaza el código anterior del producto, pero a menos que haya eliminado una función, no tiene sentido quitar la prueba casos. Entonces 679: 1 LOC no se traduce a nada como 679: 1 vez. Puede pasar fácilmente un día * reduciendo * el número de LOC en el producto y considerarlo un tiempo bien empleado, pero rara vez vale la pena molestarse en hacerlo con los casos de prueba. –
"¿Alguien sabe cómo es posible?"
"Es posible" tener 679 veces más código de prueba porque una sola característica se puede usar de muchas maneras diferentes. Considere solo una función que toma dos parámetros. Puedo generar una gran cantidad de código de prueba para esa función que prueba las condiciones de contorno y muchas otras combinaciones de condiciones. Cuando considere la instalación/desmontaje de las pruebas, allí hay un código adicional. Dependiendo de su marco de prueba, esta sobrecarga puede aumentar significativamente la cantidad de código en las pruebas.
Lo que realmente se reduce a es el hecho de que una pieza de software se puede utilizar de muchas maneras diferentes, lo que significa que tiene muchos escenarios diferentes para probar. Esta es la belleza del software elegante, ya que un programa simple se puede aplicar a numerosos escenarios, pero eso es lo mismo que hace que la verificación y prueba de software sea tan desafiante.
Utiliza Tcl para alimentar el marco de prueba, por lo que es mucho más fácil escribir pruebas que escribir la implementación. Esto fomenta las pruebas exhaustivas, que es lo que desea en una base de datos, ¿sí? Además, una fracción justa de esas pruebas son patentadas, destinadas a probar en entornos integrados; Me imagino a algunos usuarios corporativos (o usuarios) pagados por ese tipo de cosas. También es muy posible que la misma característica se pruebe varias veces.
En cuanto a la sección 3.1 (OOM):
prueba OOM se logra mediante la simulación de errores OOM. SQLite permite una aplicación para sustituir implementación alternativa malloc() mediante la interfaz sqlite3_config (SQLITE_CONFIG_MALLOC, ...) . Los arneses de la prueba TCL y TH3 son ambos capaces de insertando una versión modificada de malloc() que puede manipularse para que falle después de un cierto número de asignaciones. Estos mallocs instrumentados se pueden configurar para que fallen solo una vez y luego comiencen volviendo a funcionar, o para continuar fallando después de la primera falla. Las pruebas de OOM son hechas en un bucle. En la primera iteración del ciclo, el malloc instrumentado está preparado para fallar en la primera asignación .A continuación, se lleva a cabo alguna operación SQLite y se realizan comprobaciones en asegúrese de que SQLite manejó correctamente el error OOM . Luego, el contador de tiempo de falla en el malloc instrumentado es aumentado en uno y la prueba es repetida. El ciclo continúa hasta que la operación completa se ejecuta hasta el final sin encontrar nunca una falla OOM simulada . Pruebas como esta se ejecutan dos veces, una vez con el malloc instrumentado para fallar solo una vez, y nuevamente con el conjunto malloc instrumentado para fallar continuamente después de la primera falla .
Tenga en cuenta que la sección 7 establece explícitamente la cobertura del 100% del núcleo según lo determinado por gcov. Estoy de acuerdo con Donal Fellows que el marco de prueba es en gran parte responsable de la cobertura de la prueba más allá de lo que sugeriría un gráfico de llamadas. Es muy diferente ver que malloc() ingresó nn nn y escribir una prueba para la misma que escribir docenas de pruebas orientadas a simular entornos donde es probable que falle malloc().
Sí, la cobertura resultante es un artefacto de diligencia, sin embargo, también lo es la selección de un marco de prueba que permita ese tipo de diligencia.
Finalmente, reiterando lo obvio, malloc() toma solo un único puntero de vacío. Esto sugiere que las pruebas escritas a su alrededor son deliberadamente diseñadas, no generadas automáticamente.
Solo como comparación, 45 MLOC es aproximadamente del mismo tamaño que Windows XP. Por supuesto, como expongo a continuación, es más fácil escribir una línea de código de prueba (y hasta el día de hoy) que escribir una línea de código de producción y sobrevivir hasta el día de hoy. Podría decirse que el "código de prueba" para XP incluye todas las líneas de código en Office 95, 98 y 2000 :-) –