Em 2018, a Apple pela próxima (terceira) vez atualizou o formato em que as informações sobre o teste de funcionamento são emitidas. Se antes era um arquivo plist, que era um xml grande, agora é um arquivo grande com a extensão xcresult, que abre através do Xcode e contém um monte de informações úteis, começando com resultados de teste com logs, capturas de tela e terminando com cobertura de destino , informações de diagnóstico sobre montagem e muito mais. A maioria dos desenvolvedores não trabalha com isso todos os dias, mas os construtores de infraestrutura neste artigo podem encontrar algo útil.
Vamos analisar os prós e os contras de atualizar o formato
Quais são as desvantagens de atualizar o formato?
- É muito pesado, o que significa que a troca desses arquivos com o servidor de CI pode ser longa.
- Se não houver Xcode, ele não abrirá (é duvidoso que o testador ou desenvolvedor não tenha o Xcode, mas ainda assim).
- Possível quebra de ferramentas de integração existentes. Aprendendo a trabalhar com algo novo novamente.
Como o novo xcresult é conveniente?
- Abre nativamente por meio do Xcode.
- Você pode transferir para colegas de controle de qualidade e desenvolvimento, mesmo se eles não tiverem um projeto local. Tudo será aberto e mostrará as informações de que você precisa.
- Contém informações abrangentes sobre a execução de testes.
- Pode ser lido não apenas pelo Xcode.
Falaremos sobre o último ponto deste artigo.
Por que ler XCResult fora do Xcode?
Se sua empresa tem processos de CI&CD configurados, então você provavelmente coleta métricas sobre construções de projeto, estabilidade e número de testes e, é claro, dados de cobertura de teste. Provavelmente, em algum lugar do Bamboo, Jenkins, Github, você abandonou os testes, o status do CI ou a porcentagem de cobertura. É costume automatizar tais operações e deixá-las à mercê de máquinas sem alma. Que ferramentas temos para isso?
A Apple, junto com o lançamento do novo formato, lançou as ferramentas xcresulttool e xccov, com as quais você pode trabalhar a partir do terminal.
O que podemos obter usando o xccov?
xcrun xccov view --report --json /path/to/your/TestScheme.xcresult
A solicitação retornará informações abrangentes sobre qual cobertura todos os destinos têm, quais métodos e quais classes são cobertas, quantas vezes eles foram executados e quais linhas foram executadas. Os objetos têm uma estrutura semelhante. Existem 4 níveis no total: raiz, destino, arquivo, função. Todos os níveis, exceto a raiz, têm um campo de nome. Todos os níveis têm os campos coveredLines e lineCoverage. É importante observar que os objetos têm seu próprio contexto. Toda a estrutura pode ser descrita em vários protocolos.
Além dos protocolos, destacamos as seguintes estruturas: CoverageReport - agregador de tudo e raiz. Ele contém uma série de objetos Target. Cada destino contém um array de File, que, por sua vez, contém um array de Function. Esses objetos irão implementar os protocolos descritos acima.
Estamos interessados no campo lineCoverage. Para compor um belo relatório (como em fastlane), vá para o campo lineCoverage e percorra todos os objetos com uma função simples:
Teremos algo semelhante a:
Coverage Report Summary: • Utils.framework: 51,04 % • NavigationAssistantKit.framework: 0,0 % • NavigationKit.framework: 35,85 % • Logger.framework: 20,32 % • FTCCardData.framework: 78,21 % • FTCFeeSDK.framework: 25,25 % • ErrorPresenter.framework: 2,8 % • MTUIKit.framework: 0,24 % • AnalyticsKit.framework: 47,52 % • EdaSDK.framework: 1,18 % • Alerts.framework: 85,19 % • Resources.framework: 39,16 % • QpayApiTests.xctest: 88,37 % • FTCFeeSDKTests.xctest: 97,91 %
PS Para que a cobertura seja coletada, você precisa adicionar o parâmetro -enableCodeCoverage YES à sua equipe de teste ou ativá-lo nas configurações do esquema no Xcode.
Que oportunidades o xcresulttool oferecerá?
Na verdade, xcresulttool não tem uma interface muito grande, mas você pode obter muitas informações dele se conhecer a estrutura de xcresult. E este é um banco de dados completo para o qual você pode fazer consultas.
É uma boa ideia começar com a própria interface:
xcrun xcresulttool --help OVERVIEW: Xcode Result Bundle Tool (version 16015) USAGE: xcresulttool subcommand [options] ... SUBCOMMANDS: export Export File or Directory from Result Bundle formatDescription Result Bundle Format Description get Get Result Bundle Object graph Print Result Bundle Object Graph merge Merge Result Bundles metadata Result Bundle Metadata version XCResultKit Version
Para ler a estrutura, precisamos apenas chamar o comando:
xcrun xcresulttool get --path /path/to/your/res.xcresult --format json
É aqui que obtemos o “índice” de nosso pacote xcresult. O que estava acontecendo, quais testes foram executados, quanto tempo demorou, onde estão as capturas de tela e logs e quais foram os avisos do compilador. O principal para nós é obter os identificadores de arquivo que contêm informações sobre os testes.
xcrun xcresulttool get --path /path/to/your/res.xcresult --format json --id {id}
Em seguida, obteremos objetos com alvos de teste, tipo de teste, que são divididos em classes de teste e ternos de teste com relatórios com logs, capturas de tela, tempo de execução e outras informações para cada teste.
Infelizmente, o motivo da falha dos testes vermelhos não será fácil de descobrir - para isso você tem que fazer outra solicitação para cada teste falhado (e na verdade, nem mesmo um!!
Para Resumo de Falhas, a mesma solicitação é usada :
xcrun xcresulttool get --path /path/to/your/res.xcresult --format json --id {id}
Mas para logs de travamento, você precisa remover --format json da solicitação, pois há apenas uma string e ao passar o formatador, a ferramenta irá gerar um erro.
O que fazer a seguir com esse conhecimento prévio?
Automatize, é claro! Se você tentar esses comandos, verá que as respostas são gigantescas e difíceis de ler. Como automatizar? Ruby, Python ... ou Swift?
Claro, rápido. Qualquer desenvolvedor iOS moderno sabe disso. O projeto é aberto no Xcode, depuração, destaque de sintaxe e tipagem forte estão disponíveis. Resumindo, um sonho! Especialmente com o advento do gerenciador de pacotes Swift.
Não é nenhum segredo que com o Swift podemos facilmente iniciar processos, detectar erros e obter resultados. No caso mais simples, podemos continuar com essa construção:
Agora só temos que explorar o formato XCResult por meio dos já familiares xcrun xcov e xcrun xcresulttool. Por exemplo, para ler a cobertura do teste, usamos:
E para obter a tabela de conteúdo XCResult, precisamos executar:
Mas como obtemos nossas queridas estruturas CoverageReport e XCResult?
Pegamos uma string de Data, que o primeiro comando Shell retornará para nós e colocará o conteúdo aqui: quicktype.io .
O serviço nos gerará algo semelhante às estruturas rápidas necessárias. É verdade que você não poderá usar o resultado "como está". Teremos que estudar a estrutura da resposta mais de perto e descartar as duplicatas. No entanto, esse trabalho não é difícil. Você pode descartar peças desnecessárias ou pode pesquisar e destacar alguns blocos de construção básicos:
Com base nisso, descreva o resto das estruturas, por exemplo:
ou mesmo essas informações sobre os computadores nos quais a execução foi realizada:
Bem, como usar isso?
Existem duas maneiras de usar nosso raspador. O primeiro é tão executável, e é aqui que a biblioteca do analisador de argumentos rápido da Apple se torna útil. Antes disso, tínhamos que escrever o processamento de argumentos nós mesmos, cobri-lo com testes e apoiá-lo. Agora, esse trabalho foi assumido por uma biblioteca popular, cujos mantenedores são confiáveis.
Existem dois comandos: obter um relatório de cobertura de teste e gerar um relatório de teste junit. Você precisa construir o projeto e executar o binário, passando os argumentos necessários:
A segunda maneira é usar este projeto como uma biblioteca. Temos um grande projeto de CI responsável pela montagem, teste e envio de nosso produto KoronaPay. Por exemplo, com base nos resultados de testes de aprovação, podemos extrair todas as falhas de asserção e travamentos em testes como este:
Ou obter testes vermelhos, analisar frascos e reiniciar apenas eles.
Como analisar? Tudo é simples e não fácil ao mesmo tempo. Para obter os detalhes do motivo da falha do teste, você precisa fazer uma solicitação adicional para xcresult usando o identificador de resumo da falha. Em seguida, extraia as informações do resumo da falha. No momento, aprendemos como procurar travamentos em testes e casos de conexão perdida, bem como descobrir os motivos. Não é difícil entender que ocorreu um travamento. Você só precisa encontrar as palavras preciosas que aparecem nos resumos de falha.
É um pouco mais difícil descobrir a causa da falha.
É aqui que o mecanismo de reflexão do swift se torna útil, o que, embora um tanto limitado, é ótimo para resolver esse problema. Encontre todos os objetos de anexo denominados kXCTAttachmentLegacyDiagnosticReportData.
Não há nada mágico sobre o método reflectProperties, é uma extensão simples para Mirror:
outra categoria de testes vermelhos é afirma. Ao contrário dos travamentos, você não pode simplesmente pesquisar a string “travado” aqui. Esses testes podem ser disfarçados como casos de conexão perdida. Para chegar ao fundo do motivo, você tem que passar por vários arrays dentro do objeto TestCase como este:
Para tais operações, nossa biblioteca tem uma entidade TestsInspector que pode fornecer um resumo dos testes vermelhos. Assim, os testes vermelhos são agrupados por características no relatório.
Em vez de uma conclusão
Como todas as soluções existentes nesta área, nosso scrapper não é uma ferramenta exaustiva para analisar o xcresult. Para obter todas as informações e ver as capturas de tela, você ainda precisa abrir o xcresult por meio do Xcode. No entanto, se você configurou o CI e deseja ver os resultados do teste rapidamente, provavelmente será capaz de apreciar a combinação de junit e nosso xcscrapper em seu verdadeiro valor.