# 1+1=0: Testes na programação Visões criticas sobre a pratica programática de "testes" --- ## Apresentação --- ### Quem Sou Chicao Fernandes, pessoa desenvolvedora @ ThoughWorks. Piauiense e membro da comunidade KDE. --- ### Quê Falaremos sobre testes, ao que se propõem e o valor que tem no dia-a-dia da pessoa que coda --- ### Porquê Porque queremos ter **garantias** do funcionamento do nosso **codigo** e estabelecer limites aos **riscos** que cotidianamente lidamos e inserimos --- ### Teorema ou dedo na tomada? *Breve historia de como testes chegaram no mundo da programação* --- #### **"Dijkstra: inicio de um sonho...** **Edsger W Dijkstra** (1930-2002)  * pioneiro da ciencia da computacao * entendeu que programação era dificil * criou o termo "programacao estruturada" * aplicou provas matematicas para provar corretude de programas --- #### **Dijkstra: ...deu tudo errado"** * provas requerem fundamentos desde a base ate pegar todos os comportamentos * industria nao viu viu beneficio em se provar todo e qualquer programa * custo muito alto de se fazer --- #### **Hipotese, empirismo e metodo cientifico** *como garantir então que um codigo esta **correto**?* --- * uma hipotese consiste de: * enunciado * parametros * testabilidade * uma teoria consite de * conjunto de hipóteses testáveis, * possibilidade falsiabilidade sempre havendo a possibilidade de que um novo fato destrua a visão atual. --- > em teoria, nosso programa é **funcional** baseado em hipoteses que formulamos e testamos --- ### O valor de um teste * dada uma especificacao(requisito), como meu codigo atende o esperado? * dado o estado atual do meu projeto, como o acrescimo de uma funcionalidade nao impacta outras? * dado o custo de alguma implementacao, qual o risco de ignorar sua verificabilidade? --- ### O que é um átomo? --- #### Por onde começar a testar * programa eh composto por varios componentes que interajem entre si * alguns componentes utilizam componentes menores, que utilizam outros * ate chegar ao ponto em que devemos nos questionar qual o limite --- * o menor componente testavel(checavel) da aplicação ```python def is_input_too_big(input: str) -> bool: size = 10 return len(input) > size ... # function test def test_user_input_for_boolean(): assert is_input_too_big('blah') is not str ``` --- * o menor componente testavel(checavel) da aplicação [que acrescenta valor ao dominio de negocio] ```python def is_input_too_big(input: str) -> bool: size = 10 return len(input) > size ... # function test def test_user_input_for_acceptable_size(): assert is_input_too_big('blah') ``` --- ### O valor de um (caso) de teste --- >"a classe `UserInput` deve averiguar valores de entrada fornecidas pelo usuário" ```python class UserInput: def __init__(self, input_size): self.size = input_size def is_input_too_big(self, input: str) -> bool: return len(input) > self.size ``` --- atingir o maximo de valor (de dominio) de um teste com o minimo de custo (de manutenção) ```python def test_user_input_for_acceptable_size(): user_input = UserInput(20); assert user_input.is_input_too_big('este é um exemplo de teste') ``` --- #### O valor de dois (casos) testes ```python def test_user_input_for_acceptable_size(): assert self.is_input_too_big('blah') def test_user_input_for_acceptable_size(): assert not self.is_input_too_big('blaaaaaaaaaaaaah') ``` --- ### Unidade e dependencia(s) --- * mas e se o suposto menor componente é composto de outro elemento programatico ? * ele é testavel? em caso positivo, devemos testá-lo? --- Vejamos no código um exemplo com a seguinte especificação: > "a classe `SystemRequest` deve realizar chamadas do metodo HTTP POST e armazenar o corpo e cabeçalho da resposta" --- ### Falhas de cobertura --- Como boa pratica de checagem, devemos tambem saber o quanto os numeros que estamos gerando de fato são confiáveis ou se não se tornaram um "teatro" --- * cobertura de testes é uma das metricas mais utilizadas para indicar qualidade * mostra a quantidade de codigo-fonte executada na aplicação --- ``` cobertura de codigo = linhas executadas/ total de linhas` ``` --- * otima metrica negativa * pessima metrica positiva > se ta baixo é ruim, mas se ta alto não garante que ta bom --- Como toda métrica que se foca em linhas de código, é fragil. A solução talvez seja se focar na logica em si. --- * cobertura de ramo (*branch coverage*) é mais confiável por que sana a questão da metrica de linhas de codigo * se foca no quesito de estruturas de controle, elemento mais relacionado a logica implementada --- ``` cobertura de ramo = ramos visitados / total de ramos ``` --- * Apesar de ser mais consistente, ainda não é possivel garantir todas as ramificações possiveis da aplicação * Nenhuma métrica de ramo leva em conta caminhos de bibliotecas externas --- ### Conclusão * clareza de requisitos implica clareza no que se quer testar * testes asseguram qualidade se vão em direção da entrega das especificações * garante a solução suficiente * design do codigo tende a ser melhor --- ### Topicos futuros * O jogo de cobertura de testes * Testes, testabilidade e design de codigo * Test Driven Development e seus estilos (classico/detroid ou mockista/londres) --- ### Referencias * Edsger W Dijkstra - Notes on structured programming * [O que é ciência e método cientifico](https://canaltech.com.br/ciencia/o-que-e-ciencia-metodo-cientifico-e-divulgacao-cientifica-155693/) * Alexander Tarlinder - Developer Testing * Gerard Meszaros - XUnit Test Patterns: Refactoring Test Code * Kent Beck - Test Driven Development --- ### Obrigado - http://chicao.io - `chicao` @ github - `chicao` @ discord - `chicao` @ reddit - `__chicao__` @ twitter - `chicaofernandes` @ telegram - t.me/chicontos @ telegram channel - mail@chicao.io ---