Testando sua App PHP através de TDD

Palestra apresentada no Darkmira Tour PHP 2016

Transcript

1. TESTANDO SUA APLICAÇÃO PHP ATRAVÉS DE TDD
2. Hello! Sou Daniela Pitta Estou aqui para falar sobre TDD aplicado ao código PHP. Você pode me achar por @dlpitta
3. 60 bilhões de dólares Custo de bugs a economia dos EUA por ano 78% Desenvolvedores enxergam TDD como melhoria de produtividade 300% Projetos ágeis são mais sucedidos do que os não-ágeis Fonte: TypeMock
 Dados de 2011
4. POR QUE NÃO TESTAMOS? É impossível testar tudo. É suicídio não testar nada. Você deve testar coisas que podem quebrar. !
5. TESTES AUTOMATIZADOS E TDD Testes automatizados permitem: • Testar o sistema de maneira contínua a um preço justo. • Descobrir o problema mais cedo. • Aumentar a produtividade (caso a medida seja linhas de código sem defeito).
6. TDD A ideia é escrever testes automatizados ao longo do desenvolvimento do sistema, mas TDD sugere que o teste seja feito antes da implementação.
7. TESTES DE UNIDADES Testes de unidade permitem: • Testar uma unidade do sistema. • Garantir que uma parte do sistema funcione. Desenvolvedores quando pensam em teste de software, geralmente imaginam um teste que cobre o sistema inteiro.
8. ESCREVENDO O PRIMEIRO TESTE Cenário: Em um sistema veterinário precisamos saber a dosagem da medicação de um gato.
9. PHPUNIT Framework de Testes Unitários para PHP.
10. COMPOSER.JSON { "autoload": { "psr-0": {"Application\\": "src/"} }, "require-dev": { "phpunit/phpunit" : "*" } }
11. COMPOSER INSTALL
12. ESTRUTURA DE PASTAS composer.json composer.lock src vendor
13. GATOTEST.PHP use PHPUnit_Framework_TestCase as PHPUnit; require_once '../../../src/Application/gato.php'; class GatoTest extends PHPUnit { public function testCalculaDosagem() { $gato = new Gato("Joy", 2, 40, "SRD"); $this->assertEquals(40, $gato->calculaDosagem()); }
14. PHPUNIT -DEBUG GATOTEST.PHP
15. GATO.PHP class Gato { private $nome; private $peso; private $altura; private $raca; public function __construct($nome, $peso, $altura, $raca) { $this->nome = $nome; $this->peso = $peso; $this->altura = $altura; $this->raca = $raca; } public function calculaDosagem() { $dosagem = ($this->peso - 1) * $this->altura; return $dosagem; } }
16. PHPUNIT -DEBUG GATOTEST.PHP
17. GATO.PHP public function verificaPossilidadeDoenca() { if ($dosagem < 5) { return true; }
18. GATOTEST.PHP public function testVerificaPossibilidadeDoenca() { $gato = new Gato("Joy", 2, 40, "SRD"); $gato->calculaDosagem(); $gato->verificaPossibilidadeDoenca(); }
19. PHPUNIT -DEBUG GATOTEST.PHP
20. GATO.PHP public function verificaPossilidadeDoenca() { if ($dosagem < 5) { return true; } else ($dosagem > 5) { return false; } }
21. PHPUNIT -DEBUG GATOTEST.PHP
22. REFLETINDO SOBRE O QUE FOI FEITO O ciclo do processo realizado foi:
 • Escrevemos um teste de unidade para uma nova funcionalidade.
 • Vimos o teste falhar.
 • Implementamos um código mais simples para resolver o problema.
23. ESSE CICLO É CONHECIDO POR TEST-DRIVEN- DEVELOPMENT Ou Desenvolvimento Guiado por Testes. !
24. ESSE CICLO TAMBÉM É CONHECIDO POR VERMELHO, VERDE E REFACTOR !
25. ESCREVA UM TESTE QUE FALHE !
26. FAÇA O TESTE PASSAR !
27. AGORA REFATORE O CÓDIGO !
28. EVOLUINDO NOS TESTES Cenário: Em um sistema veterinário precisamos saber se qual doença um gato pode desenvolver apenas pela sua raça.
29. BABY STEPS A ideia de sempre tomar o passo mais simples que resolva o problema naquela momento (e faça o teste passar).
30. BABY STEPS OU PASSOS DE BEBÊ O ciclo do processo realizado foi:
 • No início foi implementada alterações mais simples.
 • Mas foi feito tantas vezes que ficou longe da implementação ideal.
 • O desenvolvedor deve buscar uma solução mais simples e não uma modificação mais simples.
31. OS BABY-STEPS SERVEM PARA AJUDAR O DESENVOLVEDOR A ENTENDER MELHOR O PROBLEMA E DIMINUIR O PASSO. !
32. BOAS PRÁTICAS Todas as boas práticas que o desenvolvedor utiliza no código de produção podem ser utilizadas no código de teste também.
33. REPETIÇÃO DE CÓDIGO ENTRE TESTES Análise: • Observe na quantidade de código repetido no testes.
 • Pense se houver alguma modificação no código de produção você terá trabalho para aplicar isso nos testes.
34. COM APENAS 3 TESTES O CÓDIGO SE REPETE. public function testDeveRetornar0SeGatoSaudavel { $gato = new Gato("Luke", 3, 60, "SRD"); //Código de Verificação } public function testDeveRetornar1SeGatoDoente { $gato = new Gato("Fred", 4, 55, "SRD"); //Código de Verificação } public function testDeveRetornar2SeGatoEstavel { $gato = new Gato("Atom", 3, 55, "SRD"); //Código de Verificação }
35. A SOLUÇÃO PORTANTO É ESCREVER ESSE CÓDIGO EM APENAS UM LUGAR. private $gato; protected function setUp() { $this->gato = new Gato(); parent::setUp(); } public function testDeveRetornar0SeGatoSaudavel { //Código de Verificação } public function testDeveRetornar1SeGatoDoente { //Código de Verificação } public function testDeveRetornar2SeGatoEstavel { //Código de Verificação }
36. NOMENCLATURA DE ARQUIVOS Toda classe deve ter seu par para teste: • nomeClasse.php • <nomeClasse>Test.php
37. NOMENCLATURA DE ARQUIVOS Escrever o caso de teste usando o pós-fixo test: • A classe tem o método algumaCoisa()
 • Deve-se criar o método testAlgumaCoisa()
38. UNDERSCORE NO NOME DO TESTE Pode-se usar underscore no nome dos testes: • test_deve_retornar_zer o_se_gato_saudavel()
39. TESTES REPETIDOS Faz sentido apagar um teste? • Se a funcionalidade foi removida, o desenvolvedor, deve atualizar a bateria de testes e apagar todos os testes relacionados a ela.
40. ESCREVENDO BOAS ASSERÇÕES Como garantir que testes falhem na hora certa? • Utilização do método assertEquals()
 • Para que ele exiba a mensagem de erro correta, o desenvolvedor deve passar os parâmetros na ordem.
41. ESCREVENDO BOAS ASSERÇÕES $gato = $gatoQueVeioSobMetodoTeste(); $this->assertEquals("Luke", $gato->getNome()); $this->assertEquals(40, $gato->calculaDosagem());
42. SEPARANDO AS CLASSES DE TESTE Onde guardar as classes de teste? • A sugestão é separar as classes de produção e as classes de teste respectivamente separadas nas pastas src e tests.
43. QUANDO NÃO USAR TDD Vimos diversas vantagens em escrita de testes de unidade e TDD, mas será que devemos fazer uso da prática 100% do tempo?
44. EM MOMENTOS NOS QUAIS O DESENVOLVEDOR JÁ SABE COMO RESOLVER O PROBLEMA, TANTO NA IMPLEMENTAÇÃO E DESIGN. !
45. DURANTE A ESCRITA DE CÓDIGO QUE LIDA COM INFRAESTRUTURA OU CAMADA DE VISUALIZAÇÃO. !
46. UTILIZAR O OUTRO TDD (TESTE DEPOIS DO DEPLOY). !
47. “ Caso o desenvolvedor opte por não usar TDD, espera-se que ele, após a implementação, escreva testes para aquela funcionalidade, sejam eles de unidade ou integração.
48. ERROS COMUNS EM TDD Ao praticar TDD, alguns desenvolvedores cometem alguns deslizes que podem prejudicar o feedback da prática.
49. ESCREVER O TESTE E NÃO O VER FALHAR. !
50. ESQUECER A REFATORAÇÃO E PARTIR PARA O PRÓXIMO TESTE. !
51. NÃO COMEÇAR PELO CENÁRIO SIMPLES E IR EVOLUINDO. !
52. “ Tenha o fluxo do TDD como mantra.
53. Thanks! ALGUMA PERGUNTA? Você pode me encontrar como @dlpitta daniela.pdj@gmail.com