blue - ios guidelines font

El resultado de la cobertura del código no es exacto a la cobertura real en Xcode 7

Question

Estoy ejecutando casos de prueba en una aplicación con datos de cobertura de código habilitados Xcode 7 Beta 2. Pero solo puedo obtener pocos datos de cobertura de archivos mientras todos mis casos de prueba se ejecutan correctamente.

Algunos archivos han cubierto todos los códigos por casos de prueba de unidad, pero aún muestran una cobertura de código del 3%.

Por ejemplo:

Este es el resultado de la cobertura del código, como puede ver en el lado derecho, hay una información de cuántas veces se llamaron estas líneas de código durante las pruebas. En este caso - 0.

Pero...

Aquí hay un lugar en las pruebas donde podemos ver que esta función fue llamada de hecho. ¿Cuantas veces? Oh ... al menos una vez. Este número es entregado por información en el lado derecho.

Por lo tanto, el código anterior debe marcarse como se llama, y ​​no estar en gris :-)

¿Alguien puede explicar esto? ¿Por qué pasó esto?

Answer 1

Creo que descubrí lo que está haciendo la cobertura de XCTest y tiene sentido:

Mi configuración:

class1 compilado en target1

Class2 compilado en target1 y en target2

Configuración de prueba:

import XCTest
@testable import target1

class MyTests: XCTestCase {
    func testSomething() {
        someMethodFromClass1()
        someMethodFromClass2()
    }
}

Lo que encuentro es que class1 (compilado en target1) muestra cobertura de prueba y class2 (compilado en target1 y target2) no muestra cobertura de prueba.

Entonces, me parece que un método probado muestra una cobertura de 0 cuando existe al menos un objetivo donde no se prueba este método.

Y esto tiene mucho sentido, porque probar un método en un objetivo no dice nada sobre cómo se comporta en un objetivo diferente.

Apple quiere que probemos todos los objetivos.

Actualización Una pista más para respaldar esta teoría:

ir al navegador de informes

y haga clic en la cobertura.

Si tiene más de un objetivo, verá sus archivos agrupados por destino.

Y si tiene un archivo en dos destinos, verá su archivo dos veces.

Si tiene un archivo en ambos destinos, se muestra la cobertura del código de este archivo para ambos objetivos. Y (al menos en mis proyectos) un archivo tiene diferentes líneas azules en cada objetivo:

cobertura en el objetivo 1:

cobertura del mismo archivo en el mismo proyecto en la misma ejecución de prueba en el objetivo 2:

Si observa la cobertura de su prueba en el editor de origen, Apple tiene que decidir qué cobertura le muestra. Creo que mostrar el objetivo con la cobertura más baja es lo mejor que Apple puede hacer en el editor de origen.

solución simple para un caso especial:

Si su único segundo objetivo es su objetivo de prueba: no compile en su objetivo de prueba y use @testable import .

Para todos los demás casos tienes que probar cada objetivo.

Answer 2

Esto sucede porque el archivo .swift de su proyecto se seleccionó para ambos objetivos de forma predeterminada.

Seleccionar y eliminar manualmente el destino de prueba para los archivos funciona para mí.

Answer 3

Tenga en cuenta que hay varias formas de cubrir el código con pruebas, puede probar todas las funciones o puede estar cubriendo todas las instrucciones de las funciones, pero es posible que no esté cubriendo todas las rutas de ejecución posibles.

O la cobertura de Xcode puede estar dañada, pero es difícil saber si no da detalles sobre qué tipo de cobertura espera que verifique.

Answer 4

Verifiqué el tema en los foros de desarrolladores de Apple y, después de leer varias publicaciones, creo que encontré la solución.

Para que la cosa funcione es necesario:

1. Elimine todos los archivos de origen de la aplicación del objetivo de prueba
2. En las fuentes de la prueba de unidad, ponga @testable import <NameOfYourModule>
3. Reconstruir y volver a ejecutar pruebas

Probé esto con mi proyecto actual, y los resultados son mucho mejores.

La receta original de la solución se puede encontrar en: http://natashatherobot.com/swift-2-xcode-7-unit-testing-access/

También parece que la funcionalidad es un poco cruda, por lo tanto, es posible que haya errores, y Apple sugiere enviar informes de errores cuando las cosas no funcionan como se espera:

Personalmente he visto resultados de cobertura de código para algunos proyectos muy grandes. En este momento, el soporte funciona mejor para aplicaciones y marcos. Si eso es lo que está probando, entonces sería mejor si pudiera presentar un informe de error en https://bugreport.apple.com para que podamos investigar sus circunstancias particulares. En ese caso, un informe de errores sería bueno sin importar el tipo de proyecto que tenga. Si es posible, es mejor en realidad en el proyecto con el informe. Si no puedes hacer eso, describe su configuración con el mayor detalle posible. Las fotos son buenas.

Tema original: https://forums.developer.apple.com/message/9733#9733

Answer 5

Funciona

1. Desde que Apple lanzó la palabra clave @testable para importar su proyecto al objetivo de prueba, ya no tiene que agregar sus archivos al objetivo:

2. Así que simplemente elimine todos los archivos de su objetivo de prueba:

3. Donde sea que necesite acceder a su archivo desde su destino de prueba, solo importe su objetivo usando: @testable import MyApp

4. Haga esto para cada archivo en su proyecto.

Entonces la cobertura del código funcionará bien.

Lea más sobre Swift 2 + Xcode 7: ¡¡¡El acceso a las pruebas unitarias fue fácil!

Si necesita saber cómo trabajar con la cobertura de códigos, lea ¿Cómo usar la cobertura de códigos en Xcode 7?

Como @Gerd Castan mencionó anteriormente es: "Así que me parece que un método probado muestra una cobertura de 0 cuando existe al menos un objetivo donde no se prueba este método".

La solución es simple. No permita que el compilador piense que este archivo está incluido en más de un objetivo, en lugar de eso, importe su módulo utilizando la palabra clave @testable .