Mas primeiro, uma breve excursão histórica: a Apple WWDC (WorldWide Developers Conference), ou simplesmente dub-dub, é uma conferência que a Apple realiza na Califórnia desde o final dos anos 80. Este ano, a conferência foi realizada online pela primeira vez. E se os bilhetes anteriores foram sorteados na loteria, e aqueles que não receberam o e-mail desejado precisavam se contentar com o vídeo do site https://developer.apple.com/videos/ , este ano, por razões óbvias, não havia outras opções: todos assistiram ao vídeo ...
Então, o que você viu dos testes lá?
Farei uma reserva imediatamente de que, na WWDC 2020, não houve uma grande sessão geral dedicada aos testes no ecossistema da Apple, como nos anos anteriores (Testes no Xcode 2019 e Novidades nos testes de 2018 ,2017 ). As novidades dos testes em 2020 foram divididas em seis mini-sessões. Ir!
XCTSkip para seus testes
O Xcode 11.4 adicionou uma nova API para controlar o lançamento de testes com base nas condições - XCTSkip.
Frequentemente, em testes, especialmente testes de integração, existem condições ou requisitos que não são fáceis de ofuscar. Por exemplo, um aplicativo possui algumas funcionalidades específicas para um iPad que não funciona em um iPhone. Ou alguns recursos para uma versão específica do sistema operacional.
E antes, quando os testes chegavam a esses casos (verificando a funcionalidade apenas do iPad no iPhone), havia uma opção:
- Finalize o caso de teste;
- Marque o teste como aprovado e siga em frente;
- Falhar no teste.
Agora, temos um erro em que o teste atual para de ser executado e é marcado como ignorado.
Portanto, agora o XCTest tem três status para o teste aprovado em vez de dois:
Mais detalhes aqui e aqui .
Manipulação de interrupção e alerta em testes de interface do usuário
A manipulação de interrupções e alertas já estava no XCTest, mas na sessão o mecanismo de sua operação foi revelado com mais detalhes. Achei interessante nova funcionalidade adicionada no Xcode 11.4, iOS / tvOS 13.4 e macOS 10.15.4, ou seja, redefinir permissões (também conhecidas como recursos protegidos).
A conclusão é a seguinte: se antes, por exemplo, no teste nº 1, você dava acesso ao aplicativo à câmera ou aos contatos e, mais tarde, no teste nº 2, # esse acesso não era tão fácil de tirar. Para fazer isso, você precisará reinstalar o aplicativo.
Agora, usando a API para redefinir a autorização para recursos protegidos, você pode selecionar o acesso concedido anteriormente:
Class XCUIApplication {
open func resetAuthorizationStatus(for: XCUIProtectedResource)
}A redefinição de permissões faz com que o aplicativo se comporte como se nunca tivesse solicitado ao usuário acessar recursos protegidos antes.
Isso permite que você percorra todo o caminho com a emissão e coleta de permissões para contatos, calendário, foto, microfone, câmera e localização geográfica. No iOS, você também pode redefinir o acesso ao acesso à rede Bluetooth e teclado e, a partir do Xcode 12 / iOS 14, para dados de integridade. No Mac OS, você pode redefinir o acesso aos diretórios Área de trabalho e Downloads.
Abaixo está um exemplo de como redefinir o acesso do aplicativo às fotos:
// Example
func testAddingPhotosFirstTime() throws {
let app = XCUIApplication()
app.resetAuthorizationStatus(for: .photos)
app.launch()
// Test code...
}É importante lembrar que muitas vezes (mas nem sempre) a redefinição de permissões mata o aplicativo.
Mais detalhes aqui , aqui e aqui .
Eliminando atrasos na animação com o XCTest
Atrasos na animação, ou problemas, são comportamentos em que um quadro aparece mais tarde do que o esperado.
A palestra descreve como impedir o aparecimento de atrasos na animação do seu aplicativo, medindo e testando usando o Performance XCTests.
Ele também fornece práticas recomendadas e identifica quais atrasos são toleráveis e quais devem ser
observados : Descreve por que os atrasos críticos merecem uma investigação e correções cuidadosas. O tópico do teste de animação em si é bastante extenso e digno de um artigo separado; portanto, nos limitaremos à parte introdutória e ao link da fonte .
Triagem e diagnóstico de testes caídos
Muitas vezes, a correção de testes com falha é uma tarefa que demanda muito tempo e recursos.
O Xcode 12 terá uma nova API que facilitará a correção de testes com falha. A API deve ajudar a responder rapidamente às perguntas: o que, como, por que e o mais importante - onde caiu?
Se antes, após a queda do teste, era necessário procurar o local do acidente no
navegador de problemas ou no navegador de relatórios; com o Xcode 12, o processo de pesquisa ficou mais fácil: agora o site do acidente é destacado no próprio teste.
Um erro com realce em cinza aparece se a linha se referir a outra linha no futuro:
e em vermelho se o erro ocorreu diretamente nesta linha:
Um novo recurso conveniente - abrir o editor de código não em uma janela separada, mas diretamente no navegador de relatórios:
Além disso, um novo objeto XCTIssue foi adicionado no Xcode 12, que, além de encapsular os dados de erro que o XCTest coletou anteriormente em si (mensagem, caminho, número da linha e o sinalizador "Esperado"), agora adiciona:
- Tipos distintos;
- Descrição detalhada;
- Erro associado;
- Anexos.
Mais detalhes aqui e aqui .
Escreva testes para fazê-los falhar
O objetivo dos testadores é escrever testes para vê-los passar verde, o que significa que o produto pode ser enviado aos usuários finais. No entanto, escrever testes para vê-los falhar também é necessário, porque um teste com falha é provavelmente um bug encontrado. Portanto, precisamos escrever testes de olho no fato de que, caso falhem, teríamos informações suficientes para investigar.
Portanto, o que é sugerido:
Use mensagens legíveis por humanos em declarações:
Certifique-se de usar o tipo de declaração apropriado para sua situação:
Desembrulhe as opções opcionais para fazer com que seus testes falhem, lançando um erro em vez de falhar. O Swift fornece várias maneiras de fazer isso, mas os testes tendem a usar o XCTUnwrap, que é uma simplificação da construção de proteção.
Use waitForExistence () em vez de sleep () para esperas assíncronas.
Use XCTContext.runActivity () para aumentar a legibilidade do log de execução de teste:
E se você quiser adicionar log adicional, pode adicionar um anexo, anexar uma captura de tela ou saída do depurador, como aqui. Esse recurso é especialmente útil se seus testes forem executados em CI / CD.
Mais detalhes aqui .
Obtenha resultados da execução de teste mais rapidamente
É uma pena que, na segunda-feira de manhã, você descubra que o longo trabalho iniciado na sexta-feira à noite não funcionou até o fim, pendurado no meio ou mesmo no início. E você tem que começar sua semana de trabalho com um debriefing: por que isso aconteceu? Como você pode evitar essa situação no futuro?
O Xcode 12 apresenta ferramentas anticongelantes. Esta é uma nova opção para o teste do plano de Tempo de Execução.
Quando ativado, o Xcode define um limite de tempo para a execução de cada teste.
Se o limite for excedido, o Xcode fará o seguinte:
- Coleta um relatório (spindump);
- Mata um teste pendurado;
- Reinicia o executor de teste para que o restante do conjunto possa executar.
O relatório (spindump) exibe qual dos threads, qual função passou mais tempo. Isso permitirá que você veja o gargalo de seus testes com os olhos antes mesmo de o café / chá da manhã esfriar.
Por padrão, 10 minutos são alocados para cada teste e, se o teste for concluído mais rapidamente, o cronômetro será zerado para o próximo teste. Se você precisar de mais / menos tempo para cada teste em seu conjunto de testes, poderá alterar o valor padrão nas configurações do plano de teste.
Você também pode fazer isso usando a opção de comando xcodebuild:
xcodebuild option
-default-test-execution-time-allowance <seconds>Da mesma forma, você pode definir o tempo máximo de execução do teste:
xcodebuild option
-maximun-test-execution-time-allowance <seconds>Mesmo se você precisar definir o tempo de execução para um teste ou classe de teste específica, isso também é possível usando a API ExecutionTimeAllowance:
Class XCTestCase: XCTest {
var executionTimeAllowance: TimeInterval //
}Ajustar a execução de um teste específico economizará tempo, mas isso não é tudo o que pode ser feito para acelerar a passagem de um longo conjunto de testes.
O Xcode 12 permite executar testes em vários dispositivos ao mesmo tempo. Esse recurso é chamado de Teste Distribuído Paralelo. Os benefícios da execução de testes em vários dispositivos são óbvios - uma economia de tempo decente.
Mas, infelizmente, também existem armadilhas: a ordem de execução dos testes em paralelo não é determinística, não há garantia de que, no dispositivo nº 1 após o teste número 5, o número de teste 6. seja executado, fato que deve ser levado em consideração ao planejar o lançamento de testes usando o Parallel. Teste Distribuído.
Em geral, a ideia de executar testes em paralelo não é nova. Havia essa oportunidade antes do Xcode 12, mas foi no Xcode 12 que se tornou possível executar testes em dispositivos reais (até agora apenas com o xcodebuild).
O comando para executar testes distribuídos paralelos é o seguinte:
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' Mais detalhes aqui .
Isso conclui a revisão dos novos recursos de teste da WWDC 2020. Obrigado pela leitura até o fim.
Espero que você ache este artigo útil. Teste feliz!