Abertura da palestra - JavaScript testável - Como arquitetar seu aplicativo para capacidade de teste
Mark Trostler (Google)
O JavaScript testável é um processo. Se é necessário começar com uma folha em branco ou um aplicativo já implementado (ou em algum lugar intermediário), a capacidade de testar o código JavaScript de forma simples, limpa e eficaz é um recurso necessário. O código que não puder ser testado será reescrito.
Embora o JavaScript seja único devido à infinidade de ambientes em que é executado, há diversas metodologias "testáveis" testadas e verdadeiras de outras linguagens que também são verdadeiras para JavaScript. E, claro, ainda existem os desafios exclusivos que os desenvolvedores de JavaScript enfrentam ao escrever e testar seus códigos.
Quais padrões tornam o código testável? Quais antipadrões impedem os testes? Quais métricas e indicadores de bom senso podem ser usados para medir a capacidade de teste do nosso código? Agora que o processo de criação de código testável foi iniciado, o que isso significa?
Junte-se a mim para detalhar o processo de criação de JavaScript testável. Investigaremos ideias, padrões e metodologias que aumentam muito a capacidade de teste e, portanto, a manutenção, a exatidão e a longevidade de seu código. Se você escrever em JavaScript no lado do cliente ou do servidor, esse processo melhorará muito a qualidade do seu código.
Quebrando a matriz - testes do Android em grande escala
Thomas Knych (Google), Stefan Ramsauer (Google) e Valera Zakharov (Google)
Você está pronto para tomar o comprimido vermelho?
Os dispositivos móveis mudaram a forma com que as pessoas interagem com computadores. Isso é ótimo, mas, como engenheiros, estamos enfrentando uma matriz cada vez maior de ambientes em que o código é executado. Os dias em que apenas alguns navegadores e resoluções de tela não são mais considerados. Como os engenheiros podem lidar com a matriz? Veremos como o Google está enfrentando esse problema de teste em estações de trabalho, na nuvem e na sua cabeça...
"Estou tentando libertar sua mente, Neo. Mas só posso mostrar a porta. É você quem tem que dar uma olhada."
Automação da IU do Android
Guang Zhu (朱光) (Google) e Adam Momtaz (Google)
À medida que o Android ganha popularidade no mundo móvel, os desenvolvedores de aplicativos e os fornecedores de OEM estão explorando maneiras de executar testes de interface de usuário completos para aplicativos ou toda a plataforma. Com uma breve revisão das soluções de automação de IU existentes no Android, esta palestra apresenta a biblioteca Android UI Automator recém-lançada e continua a apresentar uma visão geral da estrutura, dos casos de uso típicos e dos fluxos de trabalho.
Appium: automação de aplicativos para dispositivos móveis
Jonathan Lipps (Laboratórios de molho)
O Appium é um servidor Node.js que automatiza aplicativos nativos e híbridos para dispositivos móveis (iOS e Android). A filosofia do Appium determina que os aplicativos não devem ser modificados para serem automatizados e que você deve ser capaz de escrever o código de teste em qualquer linguagem ou framework. O resultado é um servidor WebDriver Selenium que fala celular como um nativo. O Appium é executado em dispositivos e emuladores reais e tem o código totalmente aberto, o que o torna uma maneira maravilhosa de começar a automação de testes para dispositivos móveis. Nesta palestra, descreverei os princípios que informam o design do Appium, falarei sobre o Appium no espaço de outras estruturas de automação móvel e apresentarei a arquitetura que faz a mágica acontecer. Por fim, vou analisar o código para um teste simples de um app para dispositivos móveis totalmente novo e demonstrar o Appium executando esse teste no iPhone e no Android.
Como criar uma infraestrutura de teste para celular escalonável para o Google+ Mobile
Eduardo Bravo (Google)
Testar aplicativos nativos de maneira significativa, estável e escalonável é um desafio. O Google+ desenvolveu soluções eficientes para lidar com esses problemas, fornecendo a infraestrutura certa para cada um dos cenários complexos de teste apresentados pelos dispositivos móveis. Nossa infraestrutura de teste atual fornece as ferramentas certas para aplicativos iOS e Android para dar à nossa equipe de desenvolvimento a confiança de que novas alterações não prejudicarão os clientes existentes.
Espresso: novo teste de IU para Android
Valera Zakharov (Google)
Desenvolver um teste Android confiável deve ser tão rápido e fácil quanto fazer uma dose de café expresso. Infelizmente, com as ferramentas existentes, pode parecer mais do que fazer duas cenas, duas ou duas vezes, um molho de caramelo-molho de cima para baixo, o que é confuso e raramente consistente. O Espresso é um novo framework de testes do Android que permite criar testes de IU concisos, bonitos e confiáveis rapidamente. A API principal é pequena, previsível e fácil de aprender, mas também está aberta para personalização. Os testes do Espresso declaram expectativas, interações e declarações de forma clara, sem atrapalhar os detalhes padrão, a infraestrutura personalizada ou os detalhes confusos de implementação. Os testes são executados de maneira ideal: deixe suas esperas, sincronizações, suspensão e enquetes para trás e deixe o framework manipular e confirmar sua interface do usuário quando estiver imóvel. Comece a gostar de programar e executar testes de IU. Tente uma sequência do Espresso.
Teste de desempenho na Web com WebDriver
Michael Klepikov (Google)
Nos testes de desempenho na Web, sabemos muito bem como analisar o carregamento de uma página. No entanto, precisamos ir além do carregamento de página: os apps modernos são altamente interativos, e as operações tendem a não recarregar a página inteira, mas a atualizar. Pessoas diferentes, inclusive eu, integrei o WebDriver aos arcabouços de testes de desempenho da Web, o que ajuda, mas ainda mantém os testes de desempenho separados do restante do conjunto de testes de IU. Proponho criar recursos de teste de desempenho diretamente no próprio WebDriver, aproveitando a recém-adicionada API Logging. Isso possibilita a coleta de métricas de desempenho durante a execução de testes funcionais regulares, permitindo uma integração muito mais integrada dos testes de desempenho no fluxo geral de desenvolvimento e teste. Ele também é muito menos disruptivo aos conjuntos de ferramentas de compilação/teste personalizados que quase todas as grandes organizações criam.
Demonstrarei isso com o ChromeDriver de nova geração (WebDriver para o navegador Chromium).
Teste de dados contínuos no Google Maps
Yvette Nameth (Google) e Brendan Dhein (Google)
O teste contínuo geralmente envolve a execução de testes de unidade e integração. Mas quando os dados que seu servidor processa são, na verdade, a maior causa de mudança, como garantir que os consumidores dos dados ainda os considerem úteis e que nada falhe sob a taxa de alteração ou uma alteração ruim? Discutiremos técnicas para testes contínuos de dados com exemplos do Google Maps.
Como encontrar os culpados automaticamente em construções que falharam. Por exemplo, quem quebrou a construção?
Celal Ziftci (UCSD) e Vivek Ramavajjala (UCSD)
A criação contínua é uma das principais infraestruturas do Google. Quando uma versão falha, é fundamental identificar rapidamente a lista de alterações/CLC para que ela possa ser corrigida para que fique verde novamente.
Existem soluções de detecção de culpado para versões pequenas e médias, mas não para versões de integração grandes.
Nosso localizador de culpados encontra automaticamente o CL de culpado para grandes construções, em um período de tempo muito curto com alto sucesso. Com base no uso da produção em vários projetos nos últimos nove meses, o localizador de culpados fornece resultados muito promissores. Participe da nossa palestra para saber como implementamos o localizador de culpados, o sucesso que ele tem na produção e como é a sensação.
Investigação empírica da qualidade da linha de produtos de software
Katerina Goseva-Popstojanova (Universidade da Virgínia Ocidental)
As linhas de produtos de software exibem um alto grau de semelhança entre os sistemas na linha de produtos e um número bem especificado de variações possíveis. Com base nos dados extraídos de dois estudos de caso: uma linha de produtos industriais de tamanho médio e uma linha de produtos de código aberto grande e em evolução, exploramos empiricamente se a reutilização sistemática melhora a qualidade e possibilita uma previsão bem-sucedida de possíveis falhas futuras de falhas anteriores, métricas de código-fonte e métricas de mudança. Nossos resultados de pesquisa confirmaram, em uma configuração de linha de produtos de software, as descobertas de outras pessoas de que as falhas estão mais correlacionadas às métricas de mudança do que às métricas de código estático. Os resultados da avaliação de qualidade mostraram que embora pacotes mais antigos (incluindo semelhanças) tenham mudado continuamente, eles mantiveram baixas densidades de falha. Além disso, a qualidade da linha de produtos de código aberto melhorou à medida que ela evoluiu com os lançamentos. A previsão com base em modelos de regressão linear generalizados classificou com precisão os pacotes de acordo com as falhas pós-lançamento usando os modelos criados na versão anterior. Os resultados também revelaram que as previsões de falha pós-lançamento se beneficiam de informações adicionais da linha de produtos.
AddressSanitizer, ThreadSanitizer e MemorySanitizer: ferramentas de teste dinâmicas para C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) é uma ferramenta que encontra estouros de buffer (em pilha, heap e globais) e bugs de uso após o uso em programas C/C++. O ThreadSanitizer (TSan) encontra disputas de dados em programas C/C++ e Go. O MemorySanitizer (MSan) é uma ferramenta de trabalho em andamento que encontra usos de memória não inicializada (C++). Essas ferramentas são baseadas na instrumentação do compilador (LLVM e GCC), o que as torna muito rápidas (por exemplo, o ASan incorre em apenas duas vezes mais lentidão). Compartilharemos nossa experiência em testes de grande escala usando essas ferramentas.
Palestra de encerramento - Bebendo o oceano - Como encontrar XSS na escala do Google
Claudio Criscione (Google)
Scripting em vários locais, ou XSS, é o equivalente atual da praga negra de meia-idade no mundo dos aplicativos da web: é generalizado, é ruim e há pouca ou nenhuma forma técnica de detectá-lo até que seja tarde demais. O XSS do DOM é uma variante particularmente desagradável, já que exige que um navegador real ou equivalente seja detectado: um problema difícil com pouca solução automatizada disponível.
Precisávamos de ferramentas poderosas e com direção automática para identificar o XSS do DOM no início do ciclo de desenvolvimento, utilizáveis por engenheiros fora da equipe de segurança. O que queríamos era um produto que pudesse verificar nosso enorme, rápido e altamente complexo e corpus arcano de aplicativos... e, é claro, não encontramos nenhum. Por isso, criamos o nosso próprio: um scanner de aplicativo da web voltado para o XSS do DOM, desenvolvido com base nas tecnologias padrão do Google. Ele é executado no App Engine e utiliza o navegador Chrome poderoso e algumas centenas de CPUs como uma plataforma de verificação de segurança.
Ele também é um bom cidadão do arsenal de testes do Google: ele fica dentro da nossa infraestrutura de testes, em vez de ser o instrumento da equipe de segurança.
Nesta palestra, descreveremos nossa nova abordagem, os desafios enfrentados no escalonamento de nosso sistema para o tamanho do Google e as ideias por trás de nossos modelos de detecção e rastreamento em aplicativos com uso intensivo de JavaScript.