Buscar..


Observaciones

Dependencias :

  • Si la aplicación utiliza bibliotecas de terceros o pods de cacao, entonces esas bibliotecas o pods también deben instalarse para prueba.
  • La clase de prueba (Traje de prueba) extiende XCTestCase.

Cepillarse antes de comenzar:

  • Todas las clases de prueba tienen dos métodos en común setUp y tearDown.

  • setUp se ejecuta antes de cada testcase y tearDown después de cada testcase.

  • Los casos de prueba se ejecutan alfabéticamente.

  • En Test Driven Development, es bueno crear datos de prueba ficticios primero.

  • Los métodos de caso de prueba comienzan con la palabra clave "prueba".

  • Los métodos de prueba no aceptan parámetros y no devuelven ningún valor.

Apéndice:

Hay varios otros métodos para comparar el resultado esperado y el resultado real de una operación. Algunos de esos métodos se enumeran a continuación:

  • XCTAssertNil (expresión, comentario) genera un error si la expresión! = Nil.
  • XCTAssertNotNil (expresión, comentario) genera un error si expresión = nil.
  • XCTAssert (expresión, comentario) genera un error si la expresión == falsa.
  • XCTAssertTrue (expresión, comentario) genera un error si la expresión == falsa.
  • XCTAssertFalse (expresión, comentario) genera un error si la expresión! = Falso.
  • XCTAssertEqualObjects (expresión1, expresión2, comentario) genera una falla si expresión1 no es igual a expresión2.
  • XCTAssertEqualObjects (expresión1, expresión2, comentario) genera una falla si expresión1 es igual a expresión2.
  • XCTAssertNotEqual (expresión1, expresión2, comentario) genera un error si expresión1 == expresión2.
  • XCTAssertEqual (expresión1, expresión2, comentario) genera un error si expresión1! = Expresión2.
  • XCTAssertGreaterThanOrEqual (expresión1, expresión2, comentario) genera un error cuando (expresión1 <expresión2).

Probando un bloque de código o algún método:

  • Importe la clase, que contiene el método a probar.
  • Realizar la operación con datos ficticios.
  • Ahora compare el resultado de la operación con el resultado esperado.
- (void)testReverseString{
NSString *originalString = @"hi_my_name_is_siddharth";
NSString *reversedString = [self.someObject reverseString:originalString];
NSString *expectedReversedString = @"htrahddis_si_eman_ym_ih";
XCTAssertEqualObjects(expectedReversedString, reversedString, @"The reversed string did not match the expected reverse");
}

Alimente los datos ficticios al método bajo prueba si es necesario y luego compare los resultados esperados y reales.

Prueba de bloque asíncrono de código:

- (void)testDoSomethingThatTakesSomeTime{
XCTestExpectation *completionExpectation = [self expectationWithDescription:@"Long method"];
[self.someObject doSomethingThatTakesSomeTimesWithCompletionBlock:^(NSString *result) {
    XCTAssertEqualObjects(@"result", result, @"Result was not correct!");
    [completionExpectation fulfill];
}];
[self waitForExpectationsWithTimeout:5.0 handler:nil];
}
  • Alimente los datos ficticios al método bajo prueba si es necesario.
  • La prueba se detendrá aquí, ejecutando el ciclo de ejecución, hasta que se alcance el tiempo de espera o se cumplan todas las expectativas.
  • El tiempo de espera es el tiempo esperado para que responda el bloque asíncrono.

Medición del rendimiento de un bloque de código:

1. Para los métodos sincrónicos:

- (void)testPerformanceReverseString {
    NSString *originalString = @"hi_my_name_is_siddharth";
    [self measureBlock:^{
        [self.someObject reverseString:originalString];
    }];
}

2. Para los métodos asíncronos:

- (void)testPerformanceOfAsynchronousBlock {
   [self measureMetrics:@[XCTPerformanceMetric_WallClockTime] automaticallyStartMeasuring:YES forBlock:^{
    
    XCTestExpectation *expectation = [self expectationWithDescription:@"performanceTestWithResponse"];
    
    [self.someObject doSomethingThatTakesSomeTimesWithCompletionBlock:^(NSString *result) {
        [expectation fulfill];
    }];
    [self waitForExpectationsWithTimeout:5.0 handler:^(NSError *error) {
    }];
}];
}
  • Este bloque de medida de rendimiento se ejecuta 10 veces consecutivas y luego se calcula el promedio, y sobre la base de este resultado de rendimiento promedio se crea y se acepta la línea de base para una evaluación adicional.
  • El resultado de rendimiento se compara con los resultados de la prueba anterior y la línea de base con una desviación estándar máxima personalizable.

Ejecución de trajes de prueba:

Ejecute todas las pruebas seleccionando Producto> Prueba. Haga clic en el icono de Test Navigator para ver el estado y los resultados de las pruebas. Puede agregar un objetivo de prueba a un proyecto (o agregar una clase a una prueba) haciendo clic en el botón Agregar (más) en la esquina inferior izquierda del navegador de prueba. Para ver el código fuente de una prueba en particular, selecciónelo de la lista de pruebas. El archivo se abre en el editor de código fuente.

Nota:

Asegúrese de que la casilla de inclusión de caso de prueba unitaria esté marcada al crear un nuevo proyecto como se muestra a continuación: introduzca la descripción de la imagen aquí



Modified text is an extract of the original Stack Overflow Documentation
Licenciado bajo CC BY-SA 3.0
No afiliado a Stack Overflow