Isso soa familiar? Um app foi desenvolvido, testado e colocado em produção. E então: os usuários começam a reclamar que o app não está funcionando. No entanto, o app passa em todos os testes. Como isso pode acontecer? E como isso pode ser resolvido?

O teste é frequentemente considerado o santo graal no desenvolvimento de software. Escrever código que tenha testes completos e cobertura de código é uma cruzada na qual muitos desenvolvedores se engajam. Para atingir esse objetivo, eles embarcam em uma jornada de resultado incerto, buscando as melhores maneiras de escrever código testável, guiados por mitos e lendas de código que tem todos os cenários possíveis testados. No entanto, apenas alguns conseguem encontrar esse santo graal. Testar não é apenas uma busca espiritual; também é como um unicórnio. Desenvolvedores juniores acreditam nele — até que um dia, percebem que não há pó mágico, nenhuma magia, e pode ser apenas um mito. Esse é o dia em que se tornam desenvolvedores seniores. Embora… isso não seja verdade para todos no desenvolvimento de software.

Há, de fato, muitos códigos por aí com 100% de cobertura e cenários de teste que cobrem todos os casos de uso. Cobertura de código de 100% implica que tudo o que se sabe que pode acontecer é testado. Quando todos os possíveis cenários de uso são testados, todo o código, teoricamente, deve ser coberto. Não é difícil argumentar que ter 100% de cobertura de código é possível, ou até mesmo uma necessidade. Bibliotecas são o exemplo perfeito onde 100% de cobertura pode ser alcançado: elas fornecem funcionalidades através de uma API pública para qualquer app que as consuma. Isso torna a alta cobertura de código obrigatória, mas também relativamente “fácil” para as bibliotecas alcançarem. Se uma API com entrada A deve retornar B, é isso que precisa ser testado. Infelizmente, o mundo nem sempre é tão simples.

Aqui está uma regra simples: quanto mais próximo do usuário final, mais difícil se torna. Isso não ocorre apenas porque o chefe final — o usuário final — entra em cena. O número de variantes de teste aumenta drasticamente: dispositivos, acessos, idiomas, funções, etc. Vamos evitar discutir muito sobre testes em geral. O foco principal aqui é, claro, SAP. Como são os testes com apps Fiori?

Fiori Apps

Os apps Fiori/UI5 não são uma exceção quando se trata da complexidade de testar apps web. Para os apps Fiori, pode ser ainda mais complicado: a versão do UI5 é principalmente definida pelo Fiori Launchpad, um tema personalizado pode ser utilizado, espaços e páginas ativados, FLP local ou em nuvem, integrado a um processo complexo, etc. O ciclo de suporte dos apps é diferente daquele do Launchpad em que estão integrados. Existem muitos parâmetros que podem mudar e que estão fora do controle do desenvolvedor do app.

Além disso, testar um UI5 até alguns anos atrás era uma tarefa excessivamente complexa. O mock server incluído funcionava mais ou menos para OData v2, mas não para v4. O Blanket.js era usado para medir a cobertura de código, em uma época em que o projeto já enfrentava problemas, como: usar funções de seta resultava em um erro. O Sinon.js tornava o código testável (fakes, stubs, spies), levantando às vezes a questão se os testes de unidade passavam porque o código funcionava ou se você o “forjou” até funcionar. O test recorder incluído… funciona. O OPA5 promete tornar a escrita de testes “muito fácil”. O código OPA5 pode se tornar extenso, e quando o seu serviço OData é baseado em v4, o mock server incluído pode ser um problema.

Nos últimos anos, houve progresso. O maior salto certamente é o wdi5. O wdi5 leva a escrita de testes para UI5 a um novo nível usando um framework amplamente utilizado: o wdio. Este é um passo na direção certa: menos de fazer tudo internamente, mais: usar o que está disponível ou integrá-lo. Para cobertura de código, o middleware de cobertura de código UI5 usa o Istanbul, outra ferramenta amplamente utilizada. As SAP Fiori Tools oferecem mais ferramentas, como a visualização do Fiori Launchpad ou o serve static. O melhor que você pode obter da SAP UX é, sem dúvida, o mock server. Este mock server funciona com OData v2 e v4.

Isso agora torna o teste de apps UI5 fácil? Não.

Por quê? Testar nunca é fácil. Testar é um trabalho árduo. Cenários de teste, dados de teste e os próprios testes precisam ser criados, escritos e validados. Uma equipe inteira deve trabalhar em conjunto para que o processo de teste funcione. Continuamente. Mesmo quando o app está finalizado e em produção, os testes continuam. Afinal, um dos objetivos é saber se o app falha após alguma alteração na paisagem de produção. Mas será que os testes são complicados apenas porque são uma tarefa contínua? E quando todos conhecem os benefícios dos testes e o trabalho envolvido, por que os apps ainda falham em produção? Por que os apps não funcionam para o usuário final? E por que os apps falham para o usuário final, enquanto os testes são aprovados?

Nota: Apps são sempre testados

Um fato importante sobre os testes: os apps são testados. Quando a empresa ou o cliente atinge um determinado porte, é provável que eles possuam uma equipe de testes e ferramentas que (deveriam) garantir que os apps sejam testados. Isso pode ser um cenário de teste no SolMan, que é executado de tempos em tempos, provavelmente de forma manual por alguém que segue uma documentação passo a passo. Ou testes simples de validação de funcionamento básico (smoke tests). Esses testes podem até ser desconhecidos pelo desenvolvedor do app. Caso um desenvolvedor afirme que o app não foi testado, há uma boa chance de isso estar incorreto. Talvez não haja testes fornecidos pelo desenvolvedor, mas isso não significa que o app não foi testado de forma alguma. E não podemos esquecer: os apps são constantemente testados pelos usuários finais, cada vez que eles utilizam o app.

Usuário final vs. desenvolvedores

As ferramentas de teste mencionadas acima para UI5 são feitas por desenvolvedores, para desenvolvedores. Não importa se é configurar o mock server, escrever um teste unitário ou de integração. O público-alvo desses testes são os desenvolvedores. Por isso, o teste faz parte da documentação do SDK do UI5. É necessário conhecimento sobre como o UI5 funciona. Conhecimento em programação é essencial para escrever testes com QUnit, OPA5 ou wdi5. Além disso, é necessário entender como o app foi desenvolvido. Essas ferramentas permitem que o desenvolvedor valide os requisitos mais complexos: se os controles de UI estão presentes, qual o valor exibido e quais são suas propriedades.

Os testes são escritos por um desenvolvedor. Embora não precise ser a mesma pessoa que escreveu o código a ser testado, geralmente são (na maioria dos casos: sim, é a mesma pessoa). Embora as jornadas e o fluxo pelo app possam ser definidos pelo usuário final, cabe ao desenvolvedor traduzi-los em código. A tradução de: “Eu abro a página, seleciono uma entrada, vejo a página de detalhes” para código fica a cargo do desenvolvedor. A pessoa que escreveu o app é a mesma que escreve os testes que validam a funcionalidade correta do app. Espero que você veja o problema aqui. E não é apenas porque é a mesma pessoa: os testes são escritos em código. A maioria dos usuários finais (que deveriam ser também os testadores) tem dificuldade em ler e entender código. No entanto, deve ser o usuário final quem define e valida os testes. Mas eles estão geralmente fora desse processo, já que o código não é a linguagem que falam.

Com o desenvolvedor escrevendo tanto o app quanto os testes, é fácil e comum ajustar os testes. O desenvolvedor pode escrever testes QUnit para testar a lógica de formatação, e todos os testes passam. Mesmo quando há 4 funções de formatação e 60 testes unitários, quem valida se esses testes refletem cenários do mundo real? Ou se eles foram atualizados para refletir as últimas mudanças?

Continua na próxima semana!