Apple WWDC 2020: Neue Funktionen beim Testen von iOS

Hallo, mein Name ist Sergey und ich teste iOS-Apps bei Exness. Ende Juni 2020 endete ein weiteres WWDC. Mal sehen, was es in der Welt des Testens von iOS-Anwendungen neu gebracht hat.



Bild



Aber zuerst ein kurzer historischer Ausflug: Apple WWDC (WorldWide Developers Conference) oder einfach Dub-Dub ist eine Konferenz, die Apple seit den späten 1980er Jahren in Kalifornien abhält. In diesem Jahr fand die Konferenz erstmals online statt. Und wenn frühere Tickets in einer Lotterie verlost wurden und diejenigen, die nicht die gewünschte E-Mail erhalten hatten, mit dem Video von der Website https://developer.apple.com/videos/ zufrieden sein mussten, gab es dieses Jahr aus offensichtlichen Gründen keine anderen Optionen: Alle sahen sich das Video an ...  



Was konnten Sie von den Tests dort sehen?



Ich werde eine Reservierung sofort , dass es auf der WWDC 2020 keine große allgemeine Sitzung war zu testen im Apple - Ökosystem gewidmet, wie in den Vorjahren (Testing in Xcode 2019 und Was ist neu bei der Prüfung 2018 ,2017 ). Testneuheiten im Jahr 2020 wurden in sechs Minisitzungen verschmiert. Gehen!



XCTSkip für Ihre Tests



Xcode 11.4 hat eine neue API hinzugefügt, um den Start von Tests basierend auf den Bedingungen zu steuern - XCTSkip. 



Bei Tests, insbesondere bei Integrationstests, gibt es häufig Bedingungen oder Anforderungen, die nicht leicht zu verschleiern sind. Beispielsweise verfügt eine Anwendung über bestimmte Funktionen für ein iPad, das auf einem iPhone nicht funktioniert. Oder einige Funktionen für eine bestimmte Version des Betriebssystems.



Und zuvor, als Tests zu ähnlichen Fällen kamen (Überprüfung der Nur-iPad-Funktionalität auf dem iPhone), gab es eine Auswahl:



  • Beenden Sie den Testfall.
  • Markieren Sie den Test als bestanden und fahren Sie fort.
  • Den Test nicht bestehen.


Wir haben jetzt einen Fehler, bei dem der aktuelle Test nicht mehr ausgeführt wird und als übersprungen markiert wird. 



Somit hat XCTest jetzt drei Status für den bestandenen Test anstelle von zwei:



Bild



Weitere Details hier und hier .



Interrupt- und Alarmbehandlung in UI-Tests



Die Interrupt- und Alarmbehandlung war zuvor in XCTest, aber in der Sitzung wurde der Mechanismus des Betriebs detaillierter beschrieben. Ich fand es interessant, neue Funktionen in Xcode 11.4, iOS / tvOS 13.4 und macOS 10.15.4 hinzuzufügen, nämlich das Zurücksetzen von Berechtigungen (auch als geschützte Ressourcen bezeichnet).



Das Fazit lautet: Wenn Sie beispielsweise früher in Test 1 der Anwendung Zugriff auf die Kamera oder die Kontakte gewährt haben, ist dieser Zugriff später in Test 2 nicht so einfach zu entfernen. Dazu müssen Sie die Anwendung neu installieren.



Mithilfe der API zum Zurücksetzen der Autorisierung für geschützte Ressourcen können Sie nun den zuvor gewährten Zugriff auswählen: 



Class XCUIApplication {

	open func resetAuthorizationStatus(for: XCUIProtectedResource)

}


Durch das Zurücksetzen von Berechtigungen verhält sich die Anwendung so, als hätte sie den Benutzer noch nie zuvor aufgefordert, auf geschützte Ressourcen zuzugreifen.



Auf diese Weise können Sie die Berechtigung für Kontakte, Kalender, Foto, Mikrofon, Kamera und Geolokalisierung erteilen und sammeln. Unter iOS können Sie zusätzlich den Zugriff auf Bluetooth- und Tastaturnetzwerkzugriff und ab Xcode 12 / iOS 14 auf Integritätsdaten zurücksetzen. Unter Mac OS können Sie den Zugriff auf die Verzeichnisse Desktop und Downloads zurücksetzen.



Unten finden Sie ein Beispiel für das Zurücksetzen des App-Zugriffs auf Fotos:




// Example
func testAddingPhotosFirstTime() throws {
	let app = XCUIApplication()
	app.resetAuthorizationStatus(for: .photos)

	app.launch()

	// Test code...
}


Es ist wichtig zu beachten, dass das häufige (aber nicht immer) Zurücksetzen von Berechtigungen die Anwendung beendet.



Weitere Details hier , hier und hier .



Eliminieren von Animationsverzögerungen mit XCTest



Animationsverzögerungen oder Hitches sind Verhaltensweisen, bei denen ein Frame später als erwartet angezeigt wird.

In der Vorlesung wird beschrieben, wie Sie das Auftreten von Verzögerungen in der Animation Ihrer Anwendung verhindern, indem Sie mithilfe von Performance XCTests messen und testen.



Außerdem werden Best Practices bereitgestellt und ermittelt, welche Verzögerungen tolerierbar sind und auf welche zu achten ist:



Bild



Beschreibt, warum kritische Verzögerungen sorgfältige Untersuchungen und Korrekturen verdienen. Das Thema Testen der Animation selbst ist ziemlich umfangreich und verdient einen separaten Artikel. Wir beschränken uns daher auf den einleitenden Teil und einen Link zur Quelle .



Triage und Diagnose von Sturztests



Oft ist das Reparieren fehlgeschlagener Tests ein Schmerz, der Zeit und Ressourcen erfordert.

Xcode 12 verfügt über eine neue API, die es einfacher machen soll, fehlgeschlagene Tests zu beheben. Die API soll helfen, die Fragen schnell zu beantworten: Was, wie, warum und vor allem - wo ist sie hingefallen?



Wenn Sie früher nach dem Ende des Tests im

Issue-Navigator oder im Report-Navigator nach der Absturzstelle suchen mussten, ist der Suchvorgang mit Xcode 12 einfacher geworden: Jetzt wird die Absturzstelle im Test selbst hervorgehoben. 



Ein Fehler mit grauer Hervorhebung wird angezeigt, wenn sich die Zeile in Zukunft auf eine andere Zeile bezieht:



Bild

 

Und rot, wenn der Fehler direkt in dieser Zeile aufgetreten ist:



Bild



Eine praktische neue Funktion - Öffnen des Code-Editors nicht in einem separaten Fenster, sondern direkt im Berichtsnavigator:



Bild



Zusätzlich wurde in Xcode 12 ein neues XCTIssue-Objekt hinzugefügt, das zusätzlich zur Kapselung der Fehlerdaten, die XCTest zuvor in sich selbst gesammelt hat (Nachricht, Pfad, Zeilennummer und das Flag "Erwartet"), jetzt Folgendes hinzufügt:

 

  • Unterschiedliche Typen;

  • Detaillierte Beschreibung;

  • Zugehöriger Fehler;

  • Anhänge.



Weitere Details hier und hier .



Schreiben Sie Tests, damit sie fehlschlagen 



Das Ziel von Testern ist es, Tests zu schreiben, um zu sehen, ob sie grün sind, was bedeutet, dass das Produkt an Endbenutzer versendet werden kann. Es ist jedoch auch erforderlich, Tests zu schreiben, um zu sehen, ob sie fehlschlagen, da ein fehlgeschlagener Test höchstwahrscheinlich ein gefundener Fehler ist. Daher müssen wir Tests schreiben, um zu berücksichtigen, dass wir im Falle eines Fehlschlags über genügend Informationen verfügen, um dies zu untersuchen.

Was also empfohlen wird:



Verwenden Sie von Menschen lesbare Nachrichten in Asserts:



Bild



Stellen Sie sicher, dass Sie die Art von Asserts verwenden, die für Ihre Situation geeignet ist:



Bild



Packen Sie die optionalen Optionen aus, damit Ihre Tests abstürzen und einen Fehler auslösen, anstatt abzustürzen. Swift bietet verschiedene Möglichkeiten, dies zu tun, aber Tests verwenden normalerweise XCTUnwrap, eine Vereinfachung des Guard-Let-Konstrukts.



Bild



Verwenden Sie waitForExistence () anstelle von sleep () für asynchrone Wartezeiten.



Verwenden Sie XCTContext.runActivity (), um die Lesbarkeit des Testausführungsprotokolls zu verbessern:



Bild



Wenn Sie zusätzliche Protokollierung hinzufügen möchten, können Sie einen Anhang hinzufügen, einen Screenshot oder eine Debugger-Ausgabe wie hier anhängen. Diese Funktion ist besonders nützlich, wenn Ihre Tests in CI / CD ausgeführt werden.



Bild



Weitere Details hier .



Erhalten Sie schneller Testlaufergebnisse



Es ist eine Schande, wenn Sie am Montagmorgen feststellen, dass der lange Job, der am Freitagabend gestartet wurde, nicht bis zum Ende funktioniert hat und in der Mitte oder sogar ganz am Anfang hängt. Und Sie müssen Ihre Arbeitswoche mit einer Nachbesprechung beginnen: Warum ist das passiert? Wie können Sie diese Situation in Zukunft vermeiden? Wie könnte ich an einem Abend neuntausend Cocktails trinken?



Xcode 12 führt Frostschutzwerkzeuge ein. Dies ist eine neue Option für den Test des Execution Time Allowance-Plans.



Wenn aktiviert, legt Xcode ein Zeitlimit für die Ausführung jedes Tests fest.

Wenn das Limit überschritten wird, führt Xcode Folgendes aus:



  1. Sammelt einen Bericht (Spindump);
  2. Tötet einen Test;
  3. Startet den Testläufer neu, damit der Rest der Suite ausgeführt werden kann.


Der Bericht (Spindump) zeigt an, welcher der Threads, welche Funktion die meiste Zeit verbracht hat. Auf diese Weise können Sie den Engpass Ihrer Tests mit Ihren Augen erkennen, noch bevor Ihr morgendlicher Kaffee / Tee abgekühlt ist.



Standardmäßig werden jedem Test 10 Minuten zugewiesen. Wenn der Test schneller abgeschlossen wird, wird der Timer für den nächsten Test auf Null zurückgesetzt. Wenn Sie für jeden Test in Ihrer Testsuite mehr oder weniger Zeit benötigen, können Sie den Standardwert in den Testplaneinstellungen ändern. 



Bild



Sie können dies auch mit der Befehlsoption xcodebuild tun:



xcodebuild option
-default-test-execution-time-allowance <seconds>


Ebenso können Sie die maximale Testausführungszeit festlegen:



Bild



xcodebuild option
-maximun-test-execution-time-allowance <seconds>


Selbst wenn Sie die Ausführungszeit für einen bestimmten Test oder eine bestimmte Testklasse festlegen müssen, ist dies auch über die API executeTimeAllowance möglich:



Class XCTestCase: XCTest {
	var executionTimeAllowance: TimeInterval //    
}


Durch die Feinabstimmung der Ausführung eines bestimmten Tests sparen Sie Zeit. Dies ist jedoch nicht alles, was Sie tun können, um den Durchgang einer langen Testsuite zu beschleunigen.



Mit Xcode 12 können Sie Tests auf mehreren Geräten gleichzeitig ausführen. Diese Funktion wird als paralleles verteiltes Testen bezeichnet. Die Vorteile der Ausführung von Tests auf mehreren Geräten liegen auf der Hand - eine anständige Zeitersparnis.



Bild



Bild



Leider gibt es auch Fallstricke: Die Reihenfolge des parallelen Startens von Tests ist nicht deterministisch. Es gibt keine Garantie dafür, dass Test Nr. 6 auf Gerät Nr. 1 nach Test Nr. 5 ausgeführt wird. Diese Tatsache muss bei der Planung von Tests berücksichtigt werden, die mit Parallel gestartet werden Verteiltes Testen.



Im Allgemeinen ist die Idee, Tests parallel durchzuführen, nicht neu. Vor Xcode 12 gab es eine solche Gelegenheit, aber in Xcode 12 war es möglich, Tests auf realen Geräten durchzuführen (bisher nur mit xcodebuild).



Der Befehl zum Ausführen parallel verteilter Tests lautet wie folgt: 



xcodebuild test
    -project MyProject.xcodeproj
    -scheme MyProject
    -parallel-testing-enabled YES
    -parallelize-test-among-desinations
    -destination 'platform=iOS,name=iPhone 11'
    -destination 'platform=iOS,name=iPad pro' 


Weitere Details hier .



Damit ist die Überprüfung der neuen Testfunktionen ab WWDC 2020 abgeschlossen. Danke fürs Lesen bis zum Ende.

Ich hoffe, Sie finden diesen Artikel hilfreich. Viel Spaß beim Testen!



All Articles