iOS
Framework XCTest - testy jednostkowe

Dodawanie plików testowych do projektu Xcode

Podczas tworzenia projektu

Należy zaznaczyć „Uwzględnij testy jednostkowe” w oknie dialogowym tworzenia projektu.

Po utworzeniu projektu

Jeśli przegapiłeś sprawdzenie tego elementu podczas tworzenia projektu, zawsze możesz dodać pliki testowe później. Aby to zrobić:

1- Przejdź do ustawień projektu w Xcode

2- Idź do „Celów”

3- Kliknij „Dodaj cel”

4- W sekcji „Inne” wybierz „Pakiet testowy jednostki kakaowej”

Na koniec powinieneś mieć plik o nazwie [Your app name]Tests.swift . W Objective-C powinieneś mieć dwa pliki o nazwie [Your app name]Tests.h i [Your app name]Tests.m .

[Your app name]Tests.swift or .m będzie domyślnie zawierał:

• XCTest modułu XCTest
• [Your app name]Tests klasę rozszerzającą XCTestCase
• setUp , tearDown , testExample , testPerformanceExample

Szybki

import XCTest

class MyProjectTests: XCTestCase {

override func setUp() {
    super.setUp()
    // Put setup code here. This method is called before the invocation of each test method in the class.
}

override func tearDown() {
    // Put teardown code here. This method is called after the invocation of each test method in the class.
    super.tearDown()
}

func testExample() {
    // This is an example of a functional test case.
    // Use XCTAssert and related functions to verify your tests produce the correct results.
    
}

func testPerformanceExample() {
    // This is an example of a performance test case.
    self.measure {
        // Put the code you want to measure the time of here.
    }
}

}

Cel C

#import <XCTest/XCTest.h>

@interface MyProjectTests : XCTestCase

@end

@implementation MyProjectTests

- (void)setUp {
    [super setUp];
// Put setup code here. This method is called before the invocation of each test method in the class.
}

- (void)tearDown {
// Put teardown code here. This method is called after the invocation of each test method in the class.
    [super tearDown];
}

- (void)testExample {
// This is an example of a functional test case.
// Use XCTAssert and related functions to verify your tests produce the correct results.
}

- (void)testPerformanceExample {
// This is an example of a performance test case.
    [self measureBlock:^{
    // Put the code you want to measure the time of here.
    }];
}

@end

Dodawanie Storyboard i View Controller jako instancji do testowania pliku

Aby rozpocząć testy jednostkowe, które zostaną przeprowadzone w pliku testów i będą testować kontroler widoku i scenorys, powinniśmy wprowadzić te dwa pliki do pliku testowego.

Definiowanie kontrolera widoku

Szybki

var viewController : ViewController!

Przedstawiamy Storyboard i zainicjowanie kontrolera widoku

Dodaj ten kod do metody setUp() :

Szybki

let storyboard = UIStoryboard(name: "Main", bundle: nil)
viewController = storyboard.instantiateInitialViewController() as! ViewController

Cel C

UIStoryboard *storyboard = [UIStoryboard storyboardWithName:"Main" bundle:nil];
viewController = (ViewController *) [storyboard instantiateInitialViewController];

W ten sposób możesz napisać metody testowe, a one będą wiedziały, gdzie sprawdzić błędy. W takim przypadku istnieją kontroler widoku i storyboard.

Dodawanie metod testowych

Według Apple:

Metody testowe

Metoda testowa jest metodą instancji klasy testowej, która rozpoczyna się od testu prefiksu, nie przyjmuje parametrów i zwraca void, na przykład (void) testColorIsRed (). Metoda testowa wykonuje kod w projekcie i jeśli kod ten nie daje oczekiwanego rezultatu, zgłasza awarie za pomocą zestawu interfejsów API asercji. Na przykład wartość zwracaną przez funkcję można porównać z wartością oczekiwaną lub test może stwierdzić, że niewłaściwe użycie metody w jednej z klas zgłasza wyjątek.

Dlatego dodajemy metodę testową, używając „test” jako prefiksu metody, na przykład:

Szybki

func testSomething() {

}

Cel C

- (void)testSomething {

}

Aby faktycznie przetestować wyniki, używamy metody XCTAssert() , która przyjmuje wyrażenie logiczne, a jeśli true, oznacza test jako XCTAssert() , w przeciwnym razie oznaczy go jako nieudany.

Powiedzmy, że mamy metodę w klasie View Controller o nazwie sum() która oblicza sumę dwóch liczb. Aby to przetestować, używamy tej metody:

Szybki

func testSum(){
    let result = viewController.sum(4, and: 5)
    XCTAssertEqual(result, 9)
}

Cel C

- (void)testSum {
    int result = [viewController sum:4 and:5];
    XCTAssertEqual(result, 9);
}

Uwaga

Domyślnie nie można uzyskać dostępu do etykiety, pola tekstowego lub innych elementów interfejsu użytkownika klasy View Controller z klasy testowej, jeśli są one najpierw tworzone w pliku Storyboard. Wynika to z faktu, że są one inicjowane w loadView() klasy View Controller i nie zostanie to wywołane podczas testowania. Najlepszym sposobem na wywołanie loadView() i wszystkich innych wymaganych metod jest dostęp do właściwości view naszej właściwości viewController . Należy dodać ten wiersz przed przetestowaniem elementów interfejsu użytkownika:

XCTAssertNotNil(viewController.view)

Rozpocznij testowanie

Testowanie określonej metody

Aby przetestować określoną metodę, kliknij kwadrat obok definicji metody.

Testowanie wszystkich metod

Aby przetestować wszystkie metody, kliknij kwadrat obok definicji klasy.

Zobacz wynik testu

Jeśli obok definicji znajduje się zielony znacznik wyboru, test się powiódł.

Jeśli obok definicji znajduje się czerwony krzyżyk, test się nie powiódł.

Uruchamianie wszystkich testów

Product -> Test OR Cmd + U

Przeprowadzi wszystkie testy ze wszystkich celów testowych!

Zaimportuj moduł, który można przetestować

Klasy, struktury, wyliczenia i wszystkie ich metody są domyślnie internal . Oznacza to, że można uzyskać do nich dostęp tylko z tego samego modułu. Przypadki testowe są w innym celu, co oznacza, że znajdują się w innym module. Aby uzyskać dostęp do metody, którą chcesz przetestować, musisz zaimportować testowany moduł za pomocą słowa kluczowego @testable .

Załóżmy, że mamy główny moduł o nazwie ToDo i chcemy dla niego napisać testy. Zaimportowalibyśmy ten moduł w następujący sposób:

@testable import ToDo

Wszystkie metody testowe w pliku z tą instrukcją importu mogą teraz uzyskiwać dostęp do wszystkich internal klas, struktur, wyliczeń i wszystkich internal metod modułu ToDo .

Nigdy nie należy dodawać plików z elementami, które chcesz przetestować, do celu testowego, ponieważ może to prowadzić do trudnych do debugowania błędów.

Ładowanie i wygląd widoku wyzwalacza

Zobacz ładowanie

W teście dla kontrolera widoku chcesz czasami wyzwalać wykonanie loadView() lub loadView() viewDidLoad() . Można to zrobić, uzyskując dostęp do widoku. Załóżmy, że w teście masz instancję kontrolera widoku o nazwie sut (testowany system), a kod wygląda następująco:

XCTAssertNotNil(sut.view)

Zobacz wygląd

Możesz także uruchomić metody viewWillAppear(_:) i viewDidAppear(_:) , dodając następujący kod:

sut.beginAppearanceTransition(true, animated: true)
sut.endAppearanceTransition()

Pisanie klasy testowej

import XCTest
@testable import PersonApp

class PersonTests: XCTestCase {
    func test_completeName() {
        let person = Person(firstName: "Josh", lastName: "Brown")
        XCTAssertEqual(person.completeName(), "Josh Brown")
    }
}

Porozmawiajmy teraz o tym, co się tutaj dzieje. Linia import XCTest pozwoli nam rozszerzyć XCTestCase i użyć XCTAssertEqual (między innymi twierdzeń). Rozszerzenie XCTestCase i poprzedzenie naszej nazwy test zapewni, że Xcode automatycznie uruchomi ten test podczas uruchamiania testów w projekcie ( ⌘U lub Produkt > Test ). @testable import PersonApp zaimportuje nasz cel PersonApp , abyśmy mogli przetestować i użyć z niego klasy, takie jak Person w powyższym przykładzie. I wreszcie nasze XCTAssertEqual zapewni, że person.completeName() jest równy ciągowi "Josh Brown" .