DPF e testes de software

Estou de volta novamente…

No final do último ano houveram várias mudanças em minha rotina, o que acabou complicando a escrita de novos posts.

Realizei cursos de DevOps pela CodeOps e Arquitetura JEE e Arquitetura pela GlobalCode, o que demandou um maior tempo para estudar.

Ainda pretendo continuar a série sobre API Connect, bem como escrever algumas considerações sobre Swagger, Spring Boot e Kotlin, arquitetura que tenho testado ultimamente.

Mas voltando aos posts, recentemente terminei de ler DPF (Departamento de Polícia da Física). Eu já havia dado minhas primeiras impressões anteriormente, e agora vou concluí-las.

É interessante ver como as nossas percepções de um dado fato mudam… Lembro-me de ter mencionado:

Imagine um mundo em que as constantes físicas já não são mais constantes, um mundo onde 99,9999 vezes em cada 100 em que um ovo cai no chão ele quebra, um mundo onde o impossível sempre é possível, esse é o cenário em que a excelente HQ FBP (Departamento de Polícia da Física) trazida pela Panini através do selo Vertigo nos contextualiza.

Minhas impressões atuais mudaram, o desfecho não foi tão excelente quanto o início da trama. De qualquer forma, meu objetivo não é focar nem na trama, nem nas imagens, que continuaram psicodélicas, e sim em Testes de Software.

– Alô, 911?

– A natureza da sua emergência é… incêndio, médica, criminosa… ou sistema que não funciona mais?

Ao pensar em um mundo em que as certezas podem desaparecer a qualquer momento, em um cenário caótico sem leis e de novos comportamentos, não tem como não pensar em desenvolvimento de sistemas.

Vivemos em um mundo em que tudo que está acontecendo na HQ pode ser utilizado como paralelo na vida de um desenvolvedor.

Quem nunca teve um comportamento inesperado de uma dada funcionalidade por conta de um carácter que não deveria estar em um lugar? Ou que teve problemas de integração quando uma dada origem mudou, e gerou um comportamento inesperadamente? Ou quando a publicação ficou com resquícios de configurações anteriores ou cache, alterando o resultado pretendido?

Nesse mundo, assim como Adam Hardy, o protagonista de DPF, nos equipamos do que pudermos para investigar o que aconteceu, e tentar trazer as coisas à “normalidade”.

Se o mundo de um desenvolvedor é tão imprevisível quanto a ficção, e um alteração de um colega nosso, por exemplo, em uma parte aparentemente sem correlação pode gerar consequências catastróficas e inimagináveis, o que poderíamos fazer para minimizar nossas incertezas? Minha resposta: Testes.

Cientistas podem mensurar se a gravidade continua a agir da forma que deveria, se a pressão continua como esperado, enfim, se os alicerces da realidade permanecem seguindo o comportamento esperado. Como desenvolvedores, podemos fazer o mesmo.

Quando desenvolvemos software podemos fazer isso com ferramentas como SOAPUI, JUnit, Selenium, etc. Mais importante do porque algo não está funcionando, é saber se algum dia ele já funcionou e onde está o comportamento inesperado nesse caso.

Assim sendo, é como se lançássemos mão de alicerces bem definidos que nos dessem um mínimo de previsibilidade de que algo já funcionou e que continua a funcionar (ou não), daí a importância de saber o que seria um comportamento normal e esperado.

Uma das poucas vantagens que temos em relação à HQ é que algumas de nossas premissas têm mais garantia que não vão mudar:

• Será que preciso testar se um booleano só terá dois valore possíveis?
• Será que preciso testar se é possível inserir dados de texto em algo que é inteiro?
• Será que minha linguagem de programação vai trabalhar com dependências como o fazia há 1h atrás?

Porque, nesse caso, se a desordem e o caos afetassem inclusive os equipamentos e linguagens que utilizamos para mensurar a desordem e o caos, então meus amigos, não tem para que lançarmos mão de alicerces que testem alguma coisa…