Hoje iniciaremos mais uma śerie aqui no Blog da Agência F12 onde falaremos sobre Teste de Software. No post de hoje veremos por que testar é importante e por que você, se não escreve testes, deveria reconsiderar o quanto antes sua decisão!
Testar é garantir a qualidade do produto desenvolvido. Não só garantir, mas sempre poder afirmar que ele se mantém saudável e em pleno funcionamento. Todos nós cometemos erros, afinal somos humanos e humanos cometem erros todo o tempo. Dessa forma, é inevitável que bugs apareçam e que a medida com que nosso software evolui, eles sejam mais difíceis de serem corrigidos e controlados. Garantir que nossa aplicação permaneça 100% sem bugs é quase utópico. Falar de uma aplicação sem bugs é falar de uma aplicação que não evolui, que não cresce, que não escala.
A real necessidade então de se realizar testes é a garantia de qualidade, identificando erros e bugs de um sistema logo no início do desenvolvimento de features, ajudando a melhorar a confiança no produto, sua qualidade e sua documentação. Ao desenvolver novos módulos e funcionalidades, como garantir que tudo o que existia antes ainda funciona sem bugs e de forma plena se você não possui testes escritos? Além disso, também vale dizer que escrever um teste que utiliza seu código também é uma forma de documentar, já que ao ler o teste, você está “lendo como se utiliza o seu software”. Testes também podem ajudar em suas métricas. Como medir performance, escalabilidade, confiança, disponibilidade sem os seus respectivos testes?
O mais importante é definir que testar é essencial para fidelizar seus clientes. A satisfação e a confiança com que seu cliente utiliza sua aplicação é o principal fator pelo qual o mantém a utilizando e sem testes é difícil manter um software que evolui com alto nível de qualidade.
Tipos de testes
Temos inúmeros tipos de testes que normalmente se dividem entre testes funcionais e não funcionais. Dentro dos testes funcionais, nos preocupamos com a aplicação em si a nível de código, realizando testes unitários, de integração, de interface, etc. Já nos testes não funcionais, nos preocupamos mais com o controle de qualidade, testando nossa documentação, nossa segurança, performance, escalabilidade, etc. Perceba que essa divisão é muito similar à divisão entre requisitos funcionais e não funcionais, auxiliando assim a direcionar nosso foco e priorizar o que é mais importante de ser testado.
A figura abaixo ilustra muito bem um dilema comum quando se inicia na prática de testes.
Perceba que a medida que subimos na pirâmide nossos testes são mais caros de serem executados, assim quanto mais alto nível um teste é feito mais caro será de escrevê-lo e também para executá-lo. Já quando descemos mais a nível de métodos, módulos e classes, com os famosos testes unitários, fica mais barato executar nossos testes. Aqui não há regra. Você deve direcionar seus recursos para aquilo que é o cerne de sua aplicação. Por exemplo, caso você possua uma single page application o ideal seria focar mais em testes de interface mesmo que mais caros, já que o front-end é o ponto mais importante de sua aplicação. Já se você trabalha com back-end com muito processamento em background e serviços de mais baixo nível, nesse caso testes unitários talvez sejam mais interessantes.
Em nossa série, daremos foco ao teste unitário, visto que é o tipo de teste mais popular e que toda aplicação deveria ter. Como possuem baixo custo como visto, cobrir toda a aplicação com testes unitários já nos trás muito ganho, garantindo qualidade a nível de código e permitindo a evolução de nosso software de maneira segura. Por isso, não perca nossa série onde já veremos na semana que vem como iniciar com testes utilizando Ruby + Rspec!
Espero ver você aqui na semana que vem. Até mais!
