Apple WWDC 2020: Quoi de neuf dans les tests iOS

Bonjour, je m'appelle Sergey et je teste des applications iOS chez Exness. Fin juin 2020, une autre WWDC a pris fin. Voyons ce que cela a apporté de nouveau dans le monde des tests d'applications iOS.



image



Mais d'abord, une brève excursion historique: Apple WWDC (WorldWide Developers Conference), ou simplement dub-dub, est une conférence qu'Apple organise en Californie depuis la fin des années 1980. Cette année, la conférence s'est tenue en ligne pour la première fois. Et si des billets antérieurs étaient tirés au sort à la loterie, et que ceux qui n'avaient pas reçu l'e-mail souhaité devaient se contenter de la vidéo du site https://developer.apple.com/videos/ , alors cette année, pour des raisons évidentes, il n'y avait pas d'autres options: tout le monde a regardé la vidéo ...  



Alors, que pouvez-vous voir en testant là-bas?



Je réserve tout de suite qu'à la WWDC 2020, il n'y avait pas de grande session générale consacrée aux tests dans l'écosystème Apple, comme les années précédentes (Test dans Xcode 2019 et Quoi de neuf dans testing 2018 ,2017 ). Les nouveautés des tests en 2020 ont été étalées en six mini-sessions. Aller!



XCTSkip pour vos tests



Xcode 11.4 a ajouté une nouvelle API pour contrôler le lancement des tests en fonction des conditions - XCTSkip. 



Souvent, dans les tests, en particulier les tests d'intégration, certaines conditions ou exigences ne sont pas faciles à masquer. Par exemple, une application a des fonctionnalités spécifiques pour un iPad qui ne fonctionnent pas sur un iPhone. Ou certaines fonctionnalités pour une version spécifique du système d'exploitation.



Et avant, lorsque des tests arrivaient à de tels cas (vérification de la fonctionnalité iPad uniquement sur l'iPhone), il y avait un choix:



  • Terminez le cas de test;
  • Marquez le test comme réussi et continuez;
  • Échouer le test.


Nous avons maintenant une erreur par laquelle le test en cours s'arrête et est marqué comme ignoré. 



Ainsi, XCTest a maintenant trois statuts pour le test réussi au lieu de deux:



image



Plus de détails ici et ici .



Gestion des interruptions et des alertes dans les tests d'interface utilisateur



La gestion des interruptions et des alertes était dans XCTest auparavant, mais dans la session, le mécanisme de son fonctionnement a été révélé plus en détail. J'ai trouvé une nouvelle fonctionnalité intéressante ajoutée dans Xcode 11.4, iOS / tvOS 13.4 et macOS 10.15.4, à savoir la réinitialisation des autorisations (également appelées ressources protégées).



L'essentiel est le suivant: si auparavant, par exemple, dans le test n ° 1 vous avez donné à l'application l'accès à la caméra ou aux contacts, puis plus tard, dans le test n ° 2, cet accès n'est pas si facile à supprimer. Pour ce faire, vous devrez réinstaller l'application.



Maintenant, en utilisant l'API pour réinitialiser l'autorisation pour les ressources protégées, vous pouvez sélectionner l'accès précédemment accordé: 



Class XCUIApplication {

	open func resetAuthorizationStatus(for: XCUIProtectedResource)

}


La réinitialisation des autorisations fait que l'application se comporte comme si elle n'avait jamais demandé à l'utilisateur d'accéder aux ressources protégées auparavant.



Cela vous permet d'aller jusqu'au bout avec l'émission et la collecte d'autorisations pour les contacts, le calendrier, la photo, le microphone, la caméra et la géolocalisation. Sur iOS, vous pouvez en outre réinitialiser l'accès à l'accès réseau Bluetooth et clavier, et à partir de Xcode 12 / iOS 14, aux données de santé. Sous Mac OS, vous pouvez réinitialiser l'accès aux répertoires Bureau et Téléchargements.



Vous trouverez ci-dessous un exemple de réinitialisation de l'accès de l'application aux photos:




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

	app.launch()

	// Test code...
}


Il est important de se rappeler que souvent (mais pas toujours) la réinitialisation des autorisations tue l'application.



Plus de détails ici , ici et ici .



Éliminer les décalages d'animation avec XCTest



Les décalages d'animation, ou accrocs, sont des comportements dans lesquels une image apparaît plus tard que prévu.

La conférence décrit comment éviter l'apparition de décalages dans l'animation de votre application en mesurant et en testant à l'aide de Performance XCTests.



Il fournit également les meilleures pratiques et identifie les décalages tolérables et ceux à surveiller:



image



Décrit pourquoi les décalages critiques méritent une enquête approfondie et des corrections. Le sujet du test d'animation lui-même est assez vaste et mérite un article séparé, nous nous limiterons donc à la partie d'introduction et à un lien vers la source .



Triage et diagnostic des tests de chute



Souvent, la correction des tests échoués est une tâche difficile qui prend beaucoup de temps et de ressources.

Xcode 12 aura une nouvelle API qui devrait faciliter la correction des tests échoués. L'API devrait aider à répondre rapidement aux questions: quoi, comment, pourquoi et surtout - où est-elle tombée?



Si auparavant, après l'échec du test, vous deviez rechercher le site du crash dans le

navigateur Problèmes ou dans le navigateur de rapports, alors avec Xcode 12, le processus de recherche est devenu plus facile: maintenant, le site du crash est mis en évidence dans le test lui-même. 



Une erreur avec surbrillance grise apparaît si la ligne fait référence à une autre ligne dans le futur:



image

 

Et en rouge si l'erreur s'est produite directement dans cette ligne:



image



Une nouvelle fonctionnalité pratique - ouvrir l'éditeur de code non pas dans une fenêtre séparée, mais directement dans le navigateur de rapport:



image



De plus, un nouvel objet XCTIssue a été ajouté dans Xcode 12, qui, en plus d'encapsuler les données d'erreur que XCTest collectait auparavant en lui-même (message, chemin, numéro de ligne et le drapeau "Attendu"), ajoute maintenant:

 

  • Types distincts;

  • Description détaillée;

  • Erreur associée;

  • Pièces jointes.



Plus de détails ici et ici .



Rédiger des tests pour les faire échouer 



L'objectif des testeurs est d'écrire des tests pour les voir passer au vert, ce qui signifie que le produit peut être expédié aux utilisateurs finaux. Néanmoins, écrire des tests pour les voir échouer est également nécessaire, car un test échoué est très probablement un bogue trouvé. Ainsi, nous devons écrire des tests en gardant à l'esprit qu'en cas d'échec, nous aurions suffisamment d'informations pour enquêter.

Donc ce qui est suggéré:



Utilisez des messages lisibles par l'homme dans les assertions:



image



assurez-vous d'utiliser le type d'assertions approprié à votre situation:



image



Déballez les options facultatives pour que vos tests se bloquent en jetant une erreur plutôt qu'en plantant. Swift propose plusieurs façons de le faire, mais les tests ont tendance à utiliser XCTUnwrap, qui est une simplification de la construction guard let.



image



Utilisez waitForExistence () au lieu de sleep () pour les attentes asynchrones.



Utilisez XCTContext.runActivity () pour augmenter la lisibilité du journal d'exécution du test:



image



Et si vous souhaitez ajouter une journalisation supplémentaire, vous pouvez ajouter une pièce jointe, joindre une capture d'écran ou une sortie du débogueur comme ici. Cette fonctionnalité est particulièrement utile si vos tests s'exécutent en CI / CD.



image



Plus de détails ici .



Obtenez les résultats des tests plus rapidement



C'est dommage quand on apprend, lundi matin, que le long travail lancé le vendredi soir n'a pas fonctionné jusqu'au bout, suspendu au milieu ou même au tout début. Et vous devez commencer votre semaine de travail par un débriefing: pourquoi est-ce arrivé? Comment pouvez-vous éviter cette situation à l'avenir? Comment pourrais-je déposer neuf mille sur des cocktails en une soirée?



Xcode 12 introduit des outils anti-gel. Il s'agit d'une nouvelle option pour le test du plan d'allocation de temps d'exécution.



Lorsqu'il est activé, Xcode définit une limite de temps pour l'exécution de chaque test.

Si la limite est dépassée, Xcode effectue les opérations suivantes:



  1. Collecte un rapport (spindump);
  2. Tue un test suspendu;
  3. Redémarre le testeur pour que le reste de la suite puisse s'exécuter.


Le rapport (spindump) affiche lequel des threads, quelle fonction a passé le plus de temps. Cela vous permettra de voir le goulot d'étranglement de vos tests avec vos yeux avant même que votre café / thé du matin ne se soit refroidi.



Par défaut, 10 minutes sont allouées pour chaque test, et si le test est terminé plus rapidement, le minuteur est remis à zéro pour le test suivant. Si vous avez besoin de plus / moins de temps pour chaque test de votre suite de tests, vous pouvez modifier la valeur par défaut dans les paramètres du plan de test. 



image



Vous pouvez également le faire en utilisant l'option de commande xcodebuild:



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


De même, vous pouvez définir la durée maximale d'exécution du test:



image



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


Même si vous devez définir l'heure d'exécution pour un test ou une classe de test spécifique, cela est également possible à l'aide de l'API executionTimeAllowance:



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


Affiner l'exécution d'un test particulier vous fera gagner du temps, mais ce n'est pas tout ce qui peut être fait pour accélérer le passage d'une longue suite de tests.



Xcode 12 vous permet d'exécuter des tests sur plusieurs appareils en même temps. Cette fonctionnalité est appelée Test distribué en parallèle. Les avantages de l'exécution de tests sur plusieurs appareils sont évidents: un gain de temps décent.



image



image



Mais, malheureusement, il y a aussi des pièges: l'ordre d'exécution des tests en parallèle n'est pas déterministe, il n'y a aucune garantie que sur l'appareil n ° 1 après le test numéro 5, le test numéro 6 sera exécuté. Ce fait doit être pris en compte lors de la planification du lancement des tests en parallèle Test distribué.



En général, l'idée d'exécuter des tests en parallèle n'est pas nouvelle. Il y avait une telle opportunité avant Xcode 12, mais c'est dans Xcode 12 qu'il est devenu possible d'exécuter des tests sur des appareils réels (jusqu'à présent uniquement en utilisant xcodebuild).



La commande pour exécuter des tests distribués en parallèle est la suivante: 



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' 


Plus de détails ici .



Ceci conclut l'examen des nouvelles fonctionnalités de test de la WWDC 2020. Merci d'avoir lu jusqu'au bout.

J'espère que vous trouverez cet article utile. Bon test!



All Articles