sexta-feira, 16 de janeiro de 2015

O que é Teste Unitário?!?

Olá, noobs!

Há algum tempo atrás, no meu primeiro estágio, foi-me pedido pelo meu chefe que começasse a cobrir o código da empresa com Testes Unitários. Na época eu estava recém começando a ouvir falar em métodos ágeis, a empresa estava adotando o Scrum e eu nunca tinha feito TDD (Test Driven Development).
Entretanto, era de minha vontade aprender sobre isso, e eu já havia comentado com meu chefe e colegas de trabalho. Logo, essa tarefa veio na hora certa.
Ou será que não?
Vejam bem... Eu nunca havia feito um teste unitário, nem sequer sabia como eles deveriam ser feitos. Pesquisei na internet e achei referências a JUnit, que já sabia que era usado na empresa (embora com pouca cobertura do código). Comecei a procurar como usá-lo e fui encontrando exemplos.
Bom, antes de continuar, saibam que esse foi meu primeiro erro.
Os exemplos não eram explicativos, usavam Mocks (que eu explico o que são daqui a pouco) e cobriam códigos pequenos. Mas a ideia eu havia entendido! Eu deveria fazer testes que cobrissem (garantissem) todo o código que eu queria testar. Deveria ter um teste para cada possível entrada e saída do método!
Ou será que não?
Foi o que comecei a fazer. Porém estava muito enganado sobre o método que deveria ter utilizado. Eu cheguei a cobrir algumas classes do código da empresa, mas não conhecia profundamente a arquitetura adotada pelo sistema. Quando me deparava com métodos utilizando outras classes, não sabia como instanciar a classe dentro do teste, pois não queria ter que chamar uma instância real da classe e, quando perguntava para os desenvolvedores sêniores da minha equipe, eles apenas diziam para usar o "Mock". "Mock", de acordo com eles, era uma classe falsa, que serviria apenas ao propósito de completar o teste (passando ele ou não). Mas eu não encontrava nada sobre como fazer um "Mock" na internet.

O tempo passou. Um pouco. Eu comecei a me interessar mais por metodologias ágeis. Principalmente depois que, em uma entrevista de emprego, me indicaram um livro para ler.

Código Limpo: Habilidades Práticas do Agile Software

Não, esse livro não fala sobre testes unitários. Ao menos, não diretamente. Mas se prestou perfeitamente a me apresentar Robert C. Martin.. E é aí que eu queria chegar.

Recentemente, comecei a ler artigos do Uncle Bob (como Robert chama a si mesmo). Acabei encontrando o blog Clean Coder. Nesses artigos, ele defende incessantemente a metodologia ágil, sobretudo o TDD. Mas, para o TDD funcionar, é necessário que se saiba fazer testes unitários. E como um teste unitário é feito? Qual é a proposta?

Os testes unitários têm mais funções do que aparentam. De acordo com Uncle Bob, eles são a maior documentação do sistema. Eles devem descrever o funcionamento do sistema. Eles garantem que o sistema funcione, independente de modificações no código, afinal, quando uma mudança faz com o que o sistema não funcione mais, os testes não passam. E isso é derivado da parte anterior, de descrever o funcionamento.

Então, para criar um teste unitário, é necessário que entendamos a que nosso sistema se propõe. Precisamos saber quais são as entradas possíveis e o que não pode ser aceito. E precisamos saber as saídas esperadas. De maneira geral, existe uma breve fórmula que pode ser utilizada. Ela segue o seguinte padrão:

Dado que (eu tenha determinados dados) Quando (alguma coisa é recebida/acontece) Então (esse deve ser o retorno).

Seguindo esse padrão, é fácil percebermos que os testes unitários se distanciam brevemente do código e, acredito, devem ser feitos independente do código. Devemos seguir apenas as definições do sistema, mantendo sempre nossos testes o mais perto da fórmula acima possível.

Não vou me estender muito mais, mas prometi informações sobre mocks. Para facilitar, quem sabe inglês pode acessar diretamente esse texto do Uncle Bob: The Little Mocker, onde ele explica os diferentes tipos de Mocks.

terça-feira, 13 de janeiro de 2015

Requiem for a Noob

Olá, noobs!

Eu comecei esse blog por influência de algumas pessoas e de uma ideia genial de "compartilhar conhecimento, independente de o quanto se sabe".
A ideia é de que "sempre existe alguém que sabe menos". E, ao mesmo tempo, serve como um histórico pessoal de o que eu estou aprendendo e de como eu estou evoluindo nos assuntos de meu interesse.

Pra começo de conversa, o assunto geral do blog vai tender para a área da informática. Desde livros, teorias, linguagens, workarounds. Mas não vou me prender a esse único assunto. Eu sou um noob confesso, e não só em computação. Conforme eu for fazendo coisas diferentes que eu ache interessante compartilhar, faço um post aqui. Acima de tudo, esse é um espaço para que eu possa dissertar sobre as coisas que eu estou aprendendo. Se, de alguma forma, a informação que eu acabar disponibilizando aqui for útil para ti, faça bom uso dela. Aprenda com os erros que eu vier a cometer, discuta o assunto do post e dê ideias e ajudas no que achares conveniente.

Além disso, como comecei um projeto pessoal, em parceria com o Gabriel Oliveira e com a Kamilla Oliveira, esse blog vai servir como um espaço para eu explicar decisões tomadas com relação a esse projeto, sejam elas de arquitetura do sistema, de modo de fazer uma funcionalidade ou da tecnologia que decidirmos utilizar.


Como disse anteriormente, eu sou um noob. Estou aqui para experimentar e aprender. E, no processo, disseminar o conhecimento que eu adquirir.


Btw, devido à falta de tempo, o layout ainda está bem básico. Ele virá a melhorar. Espero.