Discours d'ouverture – Testable JavaScript – Architecting Your Application for Testable
Mark Trosler (Google)
Testable JavaScript est un processus. Que vous commenciez par une page vierge ou une application déjà implémentée (ou quelque part entre les deux), vous devez pouvoir tester votre code JavaScript de manière simple, claire et efficace. Le code qui ne peut pas être testé sera réécrit.
Bien que JavaScript soit unique en raison de la multitude d'environnements dans lesquels il s'exécute, il existe plusieurs méthodologies "testables" éprouvées d'autres langages, qui sont également vraies pour JavaScript. Bien entendu, les développeurs JavaScript doivent relever des défis uniques lorsqu'ils écrivent et testent leur code.
Quels modèles permettent de tester le code ? Quels antimodèles n'empêchent pas les tests ? Quels métriques et guides de bon sens peuvent être utilisés pour mesurer la testabilité de notre code ? Que se passe-t-il une fois que le processus de création de code test a commencé ?
Rejoignez-moi pour décomposer le processus d'écriture de code JavaScript testable. Nous examinerons les idées, les modèles et les méthodologies qui augmentent considérablement la testabilité, et par conséquent la gestion, l'exactitude et la longévité de votre code. Que vous écriviez un langage JavaScript côté client ou serveur, ce processus améliorera considérablement la qualité de votre code.
Breaking the Matrix - Android Testing Scale
Thomas Knych (Google), Stefan Ramsauer (Google) et Valera Zakharov (Google)
Prêt à prendre la pilule rouge ?
Le mobile a modifié la façon dont les humains interagissent avec les ordinateurs. C'est formidable, mais en tant qu'ingénieurs, nous sommes confrontés à une matrice d'environnements en constante évolution sur laquelle s'exécute notre code. L'époque où nous n'envisageions qu'un nombre réduit de navigateurs et de résolutions d'écran ne sera pas de retour. Comment les ingénieurs peuvent-ils gérer la matrice ? Nous allons voir comment Google lutte contre ce problème de test sur les stations de travail, dans le cloud et dans votre tête...
"J'essaie de libérer ton esprit, Neo. Mais je peux seulement vous montrer la porte. Vous êtes le seul à les traverser."
Automatisation de l'UI Android
Guang Zhu (朱光) (Google) et Adam Momtaz (Google)
Avec la popularité croissante d'Android dans le monde mobile, les développeurs d'applications et les fournisseurs OEM cherchent à mener des tests de bout en bout sur des applications ou une plate-forme complète. Après avoir examiné brièvement les solutions d'automatisation de l'interface utilisateur existantes sur Android, nous présenterons le framework Android UI Automator que nous venons de publier. Il présente en détail le framework, les cas d'utilisation types et les workflows standards.
Appium: automatisation pour les applications mobiles
Jonathan Lipps (Sauce Labs)
Appium est un serveur Node.js qui automatise les applications mobiles natives et hybrides (iOS et Android). La philosophie d'Appium stipule que les applications ne doivent pas être modifiées pour être automatisées et que vous devez être en mesure d'écrire votre code de test dans n'importe quel langage ou framework. Résultat : un serveur Web Selenium qui parle mobile comme un natif. Appium s'exécute sur des appareils et des émulateurs réels, et est entièrement Open Source. Il s'agit donc d'un excellent moyen d'utiliser l'automatisation des tests sur mobile. Au cours de cette conférence, je présenterai les principes qui guident la conception d'Appium, je parlerai d'Appium dans le domaine des autres frameworks d'automatisation mobile, et je présenterai l'architecture qui produit la magie. Pour finir, nous allons étudier le code d'un test simple d'une toute nouvelle application mobile, puis nous allons démontrer qu'Appium exécute ce test sur iPhone et Android.
Créer une infrastructure de test mobile évolutive pour Google+ pour mobile
Eduardo Bravo (Google)
Tester des applications natives de manière significative, stable et évolutive est un défi. Google+ a développé des solutions efficaces pour relever ces défis en fournissant l'infrastructure adaptée à chaque scénario de test complexe que propose le mobile. Notre infrastructure de test actuelle fournit les outils appropriés aux applications iOS et Android pour assurer à notre équipe de développement que les nouveaux changements n'auront aucune incidence sur les clients existants.
Espresso: nouveaux tests de l'interface utilisateur Android
Valera Zakharov (Google)
Développer un test Android fiable devrait être aussi rapide et facile que de prendre un expresso. Malheureusement, avec les outils existants, cela peut sembler plus fastidieux et incohérent. Espresso est un nouveau framework de test Android qui vous permet d'écrire rapidement des tests d'interface utilisateur concis, attrayants et fiables. L'API principale est petite, prévisible et facile à apprendre, mais elle est également ouverte à la personnalisation. Les tests Espresso indiquent clairement leurs attentes, leurs interactions et leurs assertions, sans distraire le code récurrent, l'infrastructure personnalisée ni les détails d'implémentation désordonnés qui perturbent l'expérience. Les tests s'exécutent de manière optimale : laissez vos temps d'attente, vos synchronisations, vos veilles et vos sondages à la traîne, et laissez le framework manipuler et valider correctement votre interface utilisateur lorsqu'elle est au repos. Essayez de rédiger et d'exécuter des tests d'interface utilisateur en essayant Espresso.
Tests des performances Web avec WebDriver
Michael Klepikov (Google)
Lors des tests de performances Web, nous savons comment analyser le chargement d'une page. Nous devons toutefois aller au-delà d'un chargement de page: les applications modernes sont très interactives, et les opérations ont tendance à ne pas actualiser la page entière, mais à la mettre à jour. Plusieurs personnes (dont moi-même) ont intégré WebDriver aux outils de test des performances Web, ce qui est utile, mais maintient les tests de performances séparés du reste de la suite de tests de l'interface utilisateur. Je propose d'intégrer des fonctionnalités de test des performances directement dans WebDriver, en exploitant l'API Logging récemment ajoutée. Il est ainsi possible de collecter des métriques de performance lors de l'exécution régulière de tests fonctionnels, ce qui permet une intégration bien plus fluide des tests de performance dans le flux de développement et de test global. Elle est également beaucoup moins perturbatrice pour les chaînes d'outils de compilation/test personnalisées que presque toutes les grandes organisations créent.
Je vous montrerai cela avec le nouveau pilote ChromeDriver (WebDriver pour le navigateur Chromium).
Test continu des données Maps
Yvette Nameth (Google) et Brendan Dhein (Google)
Les tests en continu consistent généralement à exécuter des tests unitaires et des tests d'intégration. Mais alors que les données traitées par votre serveur sont en grande partie la cause de la modification, comment vous assurez-vous que les utilisateurs les trouvent tout de même utilisables et que tout fonctionne en cas de plantage en raison d'un taux de changement ou d'un changement incorrect ? Nous allons aborder les techniques de test continu des données avec des exemples de Google Maps.
Trouver automatiquement les failles dans les compilations en échec (qui a cassé la compilation)
Çal Ziftci (UCSD) et Vivek Ramavajjala (UCSD)
La compilation continue est l'une des infrastructures clés de Google. En cas d'échec d'une compilation, il est essentiel d'identifier rapidement la liste de modifications/les listes de modifications à l'origine de la compilation, afin de pouvoir la corriger pour qu'elle redevienne verte.
Des solutions de détection des coupures existent pour les compilations de petite et moyenne taille, mais pas pour les compilations d'intégration volumineuses.
Notre outil de recherche responsable cherche automatiquement à identifier la cause du problème pour les grandes compilations dans un délai très court. D'après l'utilisation en production de plusieurs projets au cours des neuf derniers mois, l'outil de recherche de titres peut fournir des résultats très prometteurs. Retrouvez-nous pour en savoir plus sur la mise en œuvre de l'outil de recherche responsable, et découvrez son succès en production et son apparence.
Examen empirique de la qualité des gammes de produits logiciels
Katerina Goseva-Popstojanova (Université de Virginie-Occidentale)
Les gammes de produits logiciels présentent un haut degré de similarité entre les systèmes de la gamme de produits et un nombre bien précis de variantes possibles. En nous basant sur des données extraites de deux études de cas (une gamme de produits industriels de taille moyenne et une grande gamme de produits Open Source en constante évolution), nous avons exploré empiriquement si la réutilisation systématique améliore la qualité et prend en charge la prédiction des défaillances potentielles liées à des défaillances précédemment rencontrées, des métriques de code source et des métriques de modification. Nos résultats de recherche ont confirmé que, dans le cas d'une gamme de produits logiciels, les défauts d'autres défauts sont plus fortement corrélés aux métriques de modification qu'aux métriques de code statique. Les résultats de l'évaluation de la qualité ont montré que bien que les anciens packages (y compris les points communs) changent continuellement, ils conservent des densités de pannes faibles. De plus, la gamme de produits Open Source s'est améliorée en termes de qualité au fil de son développement. La prédiction basée sur des modèles de régression linéaire généralisés a classé avec précision les packages en fonction de leurs erreurs post-sortie à l'aide des modèles créés sur la version précédente. Les résultats ont également révélé que les prédictions d'interruption post-sortie bénéficient d'informations supplémentaires sur la gamme de produits.
AddressSanitizer, ThreadSanitizer et MemorySanitizer : outils de test dynamiques pour C++
Kostya serebryany (Google)
AddressSanitizer (ASan) est un outil qui détecte les dépassements de mémoire tampon (dans la pile, le tas de mémoire et les éléments généraux) et les bugs après utilisation dans les programmes C/C++. ThreadSanitizer (TSan) trouve des courses de données dans les programmes C/C++ et Go. MemorySanitizer (MSan) est un outil de travail en cours qui détecte les utilisations de mémoire non initialisée (C++). Ces outils sont basés sur une instrumentation de compilateur (LLVM et GCC), ce qui les rend très rapides (par exemple, ASan subit un ralentissement deux fois plus rapide). Nous partagerons notre expérience lors de tests à grande échelle avec ces outils.
Discours d'ouverture : boire l'océan – Trouver des XSS à l'échelle de Google
Claudio Criscione (Google)
Le script intersites (XSS) est l'équivalent moderne de la peste noire du Moyen Âge dans le monde des applications Web: il est largement répandu et peu mauvais, et il existe très peu de moyens techniques de le détecter avant qu'il ne soit trop tard. DOM XSS en est une variante particulièrement désagréable, car il nécessite un véritable navigateur ou un équivalent: un problème difficile avec peu de solution automatisée disponible.
Nous avions besoin d'outils puissants et autonomes pour identifier le DOM XSS au début du cycle de développement, que peuvent utiliser les ingénieurs externes à l'équipe de sécurité. Tout ce dont nous avions besoin, c'est un produit capable d'analyser notre immense ensemble d'applications extrêmement rapides, complexes et arcanes... Et bien sûr, nous n'en avons trouvé aucun. Nous avons donc développé l'outil d'analyse d'applications Web qui cible DOM XSS, conçu sur les technologies Google standards. Il s'exécute dans App Engine et exploite le puissant navigateur Chrome ainsi que des centaines de processeurs comme plate-forme d'analyse de la sécurité.
C'est également un citoyen citoyen de l'arsenal de test chez Google: il se trouve au sein de notre infrastructure de test, au lieu d'être l'instrument de l'équipe de sécurité.
Lors de cette conférence, nous présentons notre nouvelle approche, les difficultés liées au scaling de notre système en fonction de la taille de Google, ainsi que les idées à l'origine de nos modèles de détection et d'exploration des applications nécessitant une grande utilisation de JavaScript.