pruebas - El análisis de cobertura de prueba unitaria de XCode 5.1 falla en archivos que usan bloques

pruebas unitarias php

Question

Hoy me encargaron agregar análisis de cobertura de prueba unitaria a nuestra base de código. Hoy también es el día en que iOS 7.1 se lanza junto con XCode 5.1. De las notas de publicación:

La herramienta gcov para pruebas de cobertura de código se ha vuelto a implementar. La nueva versión usa la herramienta llvm-cov del proyecto LLVM. Es funcionalmente equivalente a la versión anterior para todas las características importantes. La ubicación de gcov dentro de Xcode también se ha movido, use xcrun para invocarlo. Si encuentra problemas, por favor presente informes de errores. Para esta versión, aún puede usar la versión anterior de gcov de GCC, que está disponible como gcov-4.2. 11919694 actualizado

Me di cuenta de esto solo después de seguir varias posts blog instructional , configurar mi entorno correctamente, generar archivos .gcda / .gcno en las carpetas de compilación del simulador al realizar las pruebas, y hacer que las herramientas de generación de informes intenten analizarlas en un informe. (es un script ./getcov que reúne las variables de entorno para pasar a los scripts lcov-1.10 para generar el informe)

El primer obstáculo fue que el nuevo programa gcov incluido no admite el argumento -v para obtener la versión, que es el primer paso de la inicialización de lcov . Parecía un no iniciador ya, pero al leer las notas de la versión anterior modifiqué el script lcov para usar la antigua versión gcov-4.2 y lo resolví.

Sin embargo, lcov error muy temprano al procesar mis archivos de datos de cobertura. Esto generó un informe con quizás los primeros 10 o más archivos alfabéticamente en mi proyecto. No es particularmente útil. La salida de error fue mínima e inútil también:

geninfo: ERROR: GCOV falló para (build_artifacts) / (class_that_errored) .gcda!

lcov script lcov para imprimir el error que estaba obteniendo (que solo produjo 11 desafortunadamente, no pude encontrar ninguna referencia en el código gcov (-io) .c) y continuar la operación en lugar de salir, así que me quedé con un muchos más archivos en el informe, pero aún así probablemente el 85% de mis archivos de origen tuvieron un error como el anterior.

El único patrón que pude distinguir entre los archivos que terminaron con éxito en el informe y los que arrojaron un error fue que cualquier archivo que usó una declaración de bloque en línea falló. Ninguno de los archivos que pasaron usó bloques de ninguna manera, y todos los archivos que he verificado que fallaron contienen bloques. Extraño.

Luego me di cuenta de que podía abrir los archivos .gcda individuales en CoverStory, incluidos los que tenían errores en la lcov comandos lcov . En la ventana de mensajes debajo del informe de cobertura, todos los archivos con errores tenían los mensajes de advertencia:

(class_that_errored) .gcno: no hay líneas para ''__copy_helper_block_''

(class_that_errored) .gcno: no hay líneas para ''__destroy_helper_block_''

Mi mejor hipótesis en este punto es que el nuevo XCode 5.1 está generando archivos .gcda que el antiguo programa gcov-4.2 no está equipado para tratar con las declaraciones de bloque.

Pero he agotado todo lo que puedo pensar en probar, por lo que estoy aquí para preguntar si alguien tiene un conocimiento que me haya perdido, o tengo alguna idea para promover el esfuerzo de depuración. O si alguien está midiendo con éxito la cobertura de las pruebas desde la actualización de XCode 5.1 de hoy con el nuevo gcov , me encantaría conocer los cambios que también tuvo que hacer.

Answer 1

El problema está en el script geninfo LCOV 1.10. Prueba para la versión actual de gcov. Lo hace analizando la cadena de versión. Como gcov ahora apunta a llvm-cov, la cadena de versión se analiza incorrectamente.

La solución es modificar la subrutina get_gcov_version () de geninfo. En la línea 1868 , cambie -v a --version . Luego reemplace la línea 1874 con:

if ($version_string =~ m/LLVM/)
{
    info("Found llvm-cov/n");
    $result = 0x40201;
}
elsif ($version_string =~ /(/d+)/.(/d+)(/.(/d+))?/)

La subrutina modificada debería verse así:

sub get_gcov_version()
{
    local *HANDLE;
    my $version_string;
    my $result;

    open(GCOV_PIPE, "-|", "$gcov_tool --version")
        or die("ERROR: cannot retrieve gcov version!/n");
    $version_string = <GCOV_PIPE>;
    close(GCOV_PIPE);

    $result = 0;
    if ($version_string =~ m/LLVM/)
    {
        info("Found llvm-cov/n");
        $result = 0x40201;
    }
    elsif ($version_string =~ /(/d+)/.(/d+)(/.(/d+))?/)
    {
        if (defined($4))
        {
            info("Found gcov version: $1.$2.$4/n");
            $result = $1 << 16 | $2 << 8 | $4;
        }
        else
        {
            info("Found gcov version: $1.$2/n");
            $result = $1 << 16 | $2 << 8;
        }
    }
    return ($result, $version_string);
}

^{NOTA: asegúrese de que --gcov-tool no esté configurado en gcov-4.2 .}

Answer 2

En lugar de modificar geninfo , creé un llvm-cov-wrapper y usé la opción de línea de comando --gcov-tool de --gcov-tool :

#!/bin/bash
# llvm-cov wrapper to make it behave more like gcov

if [ "$1" = "-v" ]; then
    echo "llvm-cov-wrapper 4.2.1"
    exit 0
else
    /usr/bin/gcov $*
fi

Answer 3

En realidad me di cuenta de que lcov está invocando gcov con la opción -b y gcov-4.2 se bloqueará en esta opción (aumentar la falla de segmentación). Si elimino la opción -b de getinfo, entonces aunque aún muestre información de error, el archivo gcov aún puede generarse.

Probablemente esa sea la razón por la que el cubrimiento todavía puede dar salida de cobertura. Así que supongo que la solución es eliminar la opción -b de lcov. Y también como sugeriste, ignora el error en getinfo

Answer 4

Para cualquier persona nueva en este hilo, tenga en cuenta que lcov-1.11 está fuera. Esto elimina el problema con la compatibilidad con gcov -v . Sin embargo, estoy usando XCode 6.1 y aún obtengo errores en algunos archivos.

geninfo: WARNING: /Users/XXX/MyFile.gcno: found unrecognized record format - skipping

Tenga en cuenta que puede agregar el --ignore-errors graph para omitir estos errores, pero el problema no está realmente resuelto.