Sempre que queremos introduzir um novo recurso ou melhorar um existente, é fácil cair na armadilha do "funciona na minha máquina": Você escreveu algum código, abriu a página correspondente e viu que funcionava. Poderíamos pensar que isso é tudo o que precisamos, mas ter um recurso funcionando é apenas uma pequena parte da conclusão desse recurso.
Queremos manter a calma sempre que lançamos uma funcionalidade e garantir um grau de certeza de que não quebramos algo acidentalmente. Existem dois processos principais que evitam que isso aconteça: testes manuais e testes automáticos. Explicamos detalhadamente o nosso processo de controlo de qualidade manual numa publicação separada do blogue, por isso só falaremos aqui das partes automáticas porque, por vezes, precisamos de robôs em vez de humanos?
O que se entende por testes automatizados?
Os testes automáticos também são código
Se alterarmos algo numa página, isso não deve quebrar subitamente uma página diferente. Se tivéssemos de testar todas as funcionalidades existentes sempre que introduzimos algo novo para nos certificarmos de que continua a funcionar, nunca conseguiríamos lançar nada! Para garantir um certo grau de segurança, temos testes automatizados. O conceito de testes automatizados não é nada de novo, e esperamos que todas as outras empresas de software também os utilizem! No entanto, pensámos que seria útil explicar porquê e como os utilizamos.
Os testes automatizados são executados sempre que alteramos algo no código. Para ir ainda mais longe, os próprios testes também são código! Mesmo que uma funcionalidade funcione quando a testamos manualmente, ela não está completa a menos que também exista um teste para ela no código. O facto de funcionar neste momento, no seu caso de teste específico, na sua máquina, não significa que continuará a funcionar indefinidamente.
Acreditamos que os testes são tão necessários quanto o próprio código, se não um pouco mais. Eles dão-nos uma definição clara do que o nosso código deve fazer e asseguram automaticamente que o faz! Podemos alterar livremente o código sem nos preocuparmos com quebras. Se os testes passarem, tudo deve funcionar como esperado!
Porque é que utilizamos testes automatizados?
Os nossos testes automatizados permitem-nos avançar mais rapidamente sem quebrar as coisas. A nossa garantia de qualidade manual é muito mais rápida porque não temos de, por exemplo, tentar criar exames com muitos nomes diferentes. Sabemos pelos nossos testes automatizados que isto funciona, por isso não precisamos de o tentar novamente!
Os testes automatizados permitem-nos avançar mais rapidamente sem quebrar as coisas
Por isso, também podemos ser muito mais minuciosos do que seria razoável fazer manualmente. Podemos testar todas as acções possíveis que o código pode tomar, mesmo aquelas que assumem que parte do site está em baixo. Naturalmente, isso nunca deve ocorrer, e testá-lo manualmente seria complicado. No entanto, podemos simplesmente fingir que o site está em baixo e ver que tudo continuará como esperado com os nossos testes automatizados!
Um aparte: As métricas não interessam
Testes automatizados sempre provocam o debate sobre quanta cobertura de teste é necessária. A cobertura é uma métrica de quanto do seu código é realmente testado pelos seus testes, dada como uma percentagem. A cobertura dos seus testes é algo que você pode rastrear automaticamente, o que torna muito fácil decidir que ela deve ser a mais alta possível. Se tivermos 100% de cobertura de testes, nada deve quebrar acidentalmente, certo?
Bem...
Digamos que temos uma função à qual passamos um número. Ela faz um cálculo altamente complexo e depois devolve-nos o resultado. O que poderíamos fazer como teste é chamar a função e depois verificar se o resultado é um número. Naturalmente, este não é um teste sensato para este código: não temos ideia se a função efectua o cálculo correto! No entanto, esse teste nos permitirá atingir 100% de cobertura de teste: todo o trecho de código foi coberto, mas não de uma forma que signifique alguma coisa.
As métricas são uma boa muleta para ver se não estamos a fazer nada de muito estranho e, por isso, usamo-las. As métricas não são, no entanto, a medida para garantir que estamos a escrever código de boa qualidade!
Tudo é importante?
Escrevemos sempre testes para tudo, mas fazemos uma distinção entre cenários
Acreditamos que cada parte do Easy LMS é essencial, pois não seria a mesma coisa sem ela! Mas, infelizmente, ainda estamos limitados por um período de tempo finito. Não é razoável testar tudo. Precisamos sempre de fazer um compromisso sobre o grau de profundidade com que queremos automatizar algo. Escrevemos sempre testes para tudo, mas diferenciamos entre cenários. Em alguns casos, testes simples como os que mencionámos anteriormente são suficientes, mas se algo for de missão crítica, vamos ainda mais longe!
Mas e se algo for de missão crítica?
Certas partes do sistema são de missão crítica. Por exemplo, se ninguém conseguir efetuar o login, não há muito que se possa fazer com o Easy LMS. Apesar de os nossos testes testarem o código de início de sessão, gostaríamos de tentar iniciar sempre a sessão antes de lançarmos uma nova funcionalidade. Fazer esta validação manualmente significaria que teríamos de gastar alguns minutos de cada vez que quiséssemos lançar algo. É claro que podemos fazer isso, mas quanto mais coisas considerarmos necessárias, mais minutos precisaremos gastar. E isto acaba por aumentar. Felizmente, podemos ir um passo mais além. Os testes que mencionámos anteriormente testam o código, mas também temos testes de aceitação. Estes interagem com o sítio Web da mesma forma que o faria no seu browser, permitindo-nos automatizar alguns dos passos de QA que, de outra forma, teríamos de dar! Isso significa que podemos usá-los para testar uma funcionalidade inteira de ponta a ponta. Voltando ao nosso exemplo anterior, já não precisamos de iniciar sessão todas as vezes para nos certificarmos de que funciona. Se não funcionar, o teste de aceitação falhará! Todos estes métodos ajudam-nos a apanhar muitos bugs antes de chegarem a si, mas afinal somos todos humanos
