Isso soa familiar? Um app foi desenvolvido, testado e colocado em produ\u00e7\u00e3o. E ent\u00e3o: os usu\u00e1rios come\u00e7am a reclamar que o app n\u00e3o est\u00e1 funcionando. No entanto, o app passa em todos os testes. Como isso pode acontecer? E como isso pode ser resolvido?<\/p>\n\n\n\n
O teste \u00e9 frequentemente considerado o santo graal no desenvolvimento de software. Escrever c\u00f3digo que tenha testes completos e cobertura de c\u00f3digo \u00e9 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\u00f3digo test\u00e1vel, guiados por mitos e lendas de c\u00f3digo que tem todos os cen\u00e1rios poss\u00edveis testados. No entanto, apenas alguns conseguem encontrar esse santo graal. Testar n\u00e3o \u00e9 apenas uma busca espiritual; tamb\u00e9m \u00e9 como um unic\u00f3rnio. Desenvolvedores juniores acreditam nele \u2014 at\u00e9 que um dia, percebem que n\u00e3o h\u00e1 p\u00f3 m\u00e1gico, nenhuma magia, e pode ser apenas um mito. Esse \u00e9 o dia em que se tornam desenvolvedores seniores. Embora… isso n\u00e3o seja verdade para todos no desenvolvimento de software.<\/p>\n\n\n\n
H\u00e1, de fato, muitos c\u00f3digos por a\u00ed com 100% de cobertura e cen\u00e1rios de teste que cobrem todos os casos de uso. Cobertura de c\u00f3digo de 100% implica que tudo o que se sabe que pode acontecer \u00e9 testado. Quando todos os poss\u00edveis cen\u00e1rios de uso s\u00e3o testados, todo o c\u00f3digo, teoricamente, deve ser coberto. N\u00e3o \u00e9 dif\u00edcil argumentar que ter 100% de cobertura de c\u00f3digo \u00e9 poss\u00edvel, ou at\u00e9 mesmo uma necessidade. Bibliotecas s\u00e3o o exemplo perfeito onde 100% de cobertura pode ser alcan\u00e7ado: elas fornecem funcionalidades atrav\u00e9s de uma API p\u00fablica para qualquer app que as consuma. Isso torna a alta cobertura de c\u00f3digo obrigat\u00f3ria, mas tamb\u00e9m relativamente \u201cf\u00e1cil\u201d para as bibliotecas alcan\u00e7arem. Se uma API com entrada A deve retornar B, \u00e9 isso que precisa ser testado. Infelizmente, o mundo nem sempre \u00e9 t\u00e3o simples.<\/p>\n\n\n\n
Aqui est\u00e1 uma regra simples: quanto mais pr\u00f3ximo do usu\u00e1rio final, mais dif\u00edcil se torna. Isso n\u00e3o ocorre apenas porque o chefe final \u2014 o usu\u00e1rio final \u2014 entra em cena. O n\u00famero de variantes de teste aumenta drasticamente: dispositivos, acessos, idiomas, fun\u00e7\u00f5es, etc. Vamos evitar discutir muito sobre testes em geral. O foco principal aqui \u00e9, claro, SAP. Como s\u00e3o os testes com apps Fiori?<\/p>\n\n\n\n
Fiori Apps<\/strong><\/p>\n\n\n\n Os apps Fiori\/UI5 n\u00e3o s\u00e3o uma exce\u00e7\u00e3o quando se trata da complexidade de testar apps web. Para os apps Fiori, pode ser ainda mais complicado: a vers\u00e3o do UI5 \u00e9 principalmente definida pelo Fiori Launchpad, um tema personalizado pode ser utilizado, espa\u00e7os e p\u00e1ginas ativados, FLP local ou em nuvem, integrado a um processo complexo, etc. O ciclo de suporte dos apps \u00e9 diferente daquele do Launchpad em que est\u00e3o integrados. Existem muitos par\u00e2metros que podem mudar e que est\u00e3o fora do controle do desenvolvedor do app.<\/p>\n\n\n\n Al\u00e9m disso, testar um UI5 at\u00e9 alguns anos atr\u00e1s era uma tarefa excessivamente complexa. O mock server inclu\u00eddo funcionava mais ou menos para OData v2, mas n\u00e3o para v4. O Blanket.js era usado para medir a cobertura de c\u00f3digo, em uma \u00e9poca em que o projeto j\u00e1 enfrentava problemas, como: usar fun\u00e7\u00f5es de seta resultava em um erro. O Sinon.js tornava o c\u00f3digo test\u00e1vel (fakes, stubs, spies), levantando \u00e0s vezes a quest\u00e3o se os testes de unidade passavam porque o c\u00f3digo funcionava ou se voc\u00ea o \u201cforjou\u201d at\u00e9 funcionar. O test recorder inclu\u00eddo… funciona. O OPA5 promete tornar a escrita de testes “muito f\u00e1cil”. O c\u00f3digo OPA5 pode se tornar extenso, e quando o seu servi\u00e7o OData \u00e9 baseado em v4, o mock server inclu\u00eddo pode ser um problema.<\/p>\n\n\n\n Nos \u00faltimos anos, houve progresso. O maior salto certamente \u00e9 o wdi5. O wdi5 leva a escrita de testes para UI5 a um novo n\u00edvel usando um framework amplamente utilizado: o wdio. Este \u00e9 um passo na dire\u00e7\u00e3o certa: menos de fazer tudo internamente, mais: usar o que est\u00e1 dispon\u00edvel ou integr\u00e1-lo. Para cobertura de c\u00f3digo, o middleware de cobertura de c\u00f3digo UI5 usa o Istanbul, outra ferramenta amplamente utilizada. As SAP Fiori Tools oferecem mais ferramentas, como a visualiza\u00e7\u00e3o do Fiori Launchpad ou o serve static. O melhor que voc\u00ea pode obter da SAP UX \u00e9, sem d\u00favida, o mock server. Este mock server funciona com OData v2 e v4.<\/p>\n\n\n\n Isso agora torna o teste de apps UI5 f\u00e1cil? N\u00e3o.<\/strong><\/p>\n\n\n\n Por qu\u00ea? Testar nunca \u00e9 f\u00e1cil. Testar \u00e9 um trabalho \u00e1rduo. Cen\u00e1rios de teste, dados de teste e os pr\u00f3prios 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\u00e1 finalizado e em produ\u00e7\u00e3o, os testes continuam. Afinal, um dos objetivos \u00e9 saber se o app falha ap\u00f3s alguma altera\u00e7\u00e3o na paisagem de produ\u00e7\u00e3o. Mas ser\u00e1 que os testes s\u00e3o complicados apenas porque s\u00e3o uma tarefa cont\u00ednua? E quando todos conhecem os benef\u00edcios dos testes e o trabalho envolvido, por que os apps ainda falham em produ\u00e7\u00e3o? Por que os apps n\u00e3o funcionam para o usu\u00e1rio final? E por que os apps falham para o usu\u00e1rio final, enquanto os testes s\u00e3o aprovados?<\/p>\n\n\n\n Nota: Apps s\u00e3o sempre testados<\/em><\/strong><\/p>\n\n\n\n Um fato importante sobre os testes: os apps s\u00e3o testados. Quando a empresa ou o cliente atinge um determinado porte, \u00e9 prov\u00e1vel que eles possuam uma equipe de testes e ferramentas que (deveriam) garantir que os apps sejam testados. Isso pode ser um cen\u00e1rio de teste no SolMan, que \u00e9 executado de tempos em tempos, provavelmente de forma manual por algu\u00e9m que segue uma documenta\u00e7\u00e3o passo a passo. Ou testes simples de valida\u00e7\u00e3o de funcionamento b\u00e1sico (smoke tests). Esses testes podem at\u00e9 ser desconhecidos pelo desenvolvedor do app. Caso um desenvolvedor afirme que o app n\u00e3o foi testado, h\u00e1 uma boa chance de isso estar incorreto. Talvez n\u00e3o haja testes fornecidos pelo desenvolvedor, mas isso n\u00e3o significa que o app n\u00e3o foi testado de forma alguma. E n\u00e3o podemos esquecer: os apps s\u00e3o constantemente testados pelos usu\u00e1rios finais, cada vez que eles utilizam o app.<\/em><\/p>\n\n\n\n Usu\u00e1rio final vs. desenvolvedores<\/strong><\/p>\n\n\n\n As ferramentas de teste mencionadas acima para UI5 s\u00e3o feitas por desenvolvedores, para desenvolvedores. N\u00e3o importa se \u00e9 configurar o mock server, escrever um teste unit\u00e1rio ou de integra\u00e7\u00e3o. O p\u00fablico-alvo desses testes s\u00e3o os desenvolvedores. Por isso, o teste faz parte da documenta\u00e7\u00e3o do SDK do UI5. \u00c9 necess\u00e1rio conhecimento sobre como o UI5 funciona. Conhecimento em programa\u00e7\u00e3o \u00e9 essencial para escrever testes com QUnit, OPA5 ou wdi5. Al\u00e9m disso, \u00e9 necess\u00e1rio entender como o app foi desenvolvido. Essas ferramentas permitem que o desenvolvedor valide os requisitos mais complexos: se os controles de UI est\u00e3o presentes, qual o valor exibido e quais s\u00e3o suas propriedades.<\/p>\n\n\n\n Os testes s\u00e3o escritos por um desenvolvedor. Embora n\u00e3o precise ser a mesma pessoa que escreveu o c\u00f3digo a ser testado, geralmente s\u00e3o (na maioria dos casos: sim, \u00e9 a mesma pessoa). Embora as jornadas e o fluxo pelo app possam ser definidos pelo usu\u00e1rio final, cabe ao desenvolvedor traduzi-los em c\u00f3digo. A tradu\u00e7\u00e3o de: “Eu abro a p\u00e1gina, seleciono uma entrada, vejo a p\u00e1gina de detalhes” para c\u00f3digo fica a cargo do desenvolvedor. A pessoa que escreveu o app \u00e9 a mesma que escreve os testes que validam a funcionalidade correta do app. Espero que voc\u00ea veja o problema aqui. E n\u00e3o \u00e9 apenas porque \u00e9 a mesma pessoa: os testes s\u00e3o escritos em c\u00f3digo. A maioria dos usu\u00e1rios finais (que deveriam ser tamb\u00e9m os testadores) tem dificuldade em ler e entender c\u00f3digo. No entanto, deve ser o usu\u00e1rio final quem define e valida os testes. Mas eles est\u00e3o geralmente fora desse processo, j\u00e1 que o c\u00f3digo n\u00e3o \u00e9 a linguagem que falam.<\/p>\n\n\n\n Com o desenvolvedor escrevendo tanto o app quanto os testes, \u00e9 f\u00e1cil e comum ajustar os testes. O desenvolvedor pode escrever testes QUnit para testar a l\u00f3gica de formata\u00e7\u00e3o, e todos os testes passam. Mesmo quando h\u00e1 4 fun\u00e7\u00f5es de formata\u00e7\u00e3o e 60 testes unit\u00e1rios, quem valida se esses testes refletem cen\u00e1rios do mundo real? Ou se eles foram atualizados para refletir as \u00faltimas mudan\u00e7as?<\/p>\n\n\n\n Continua na pr\u00f3xima semana!<\/p>\n","protected":false},"excerpt":{"rendered":" Isso soa familiar? Um app foi desenvolvido, testado e colocado em produ\u00e7\u00e3o. E ent\u00e3o: os usu\u00e1rios come\u00e7am a reclamar que o app n\u00e3o est\u00e1 funcionando. No entanto, o app passa em todos os testes. Como isso pode acontecer? E como isso pode ser resolvido? O teste \u00e9 frequentemente considerado o santo graal no desenvolvimento de […]<\/p>\n","protected":false},"author":1,"featured_media":744,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-741","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sem-categoria"],"_links":{"self":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/741","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/comments?post=741"}],"version-history":[{"count":3,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/741\/revisions"}],"predecessor-version":[{"id":745,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/741\/revisions\/745"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/media\/744"}],"wp:attachment":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/media?parent=741"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/categories?post=741"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/tags?post=741"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}