Apresentação Agile Testing GTS-Ce

Apresentação sobre Agile Testing no Grupo de Testes do Ceará.

Transcript

1. Não tem teste? Já nasceu legado. Hedley Luna
2. Quem? ·Graduado em Ciência da Computação - UECE ·Mestrando em Ciência da Computação - UECE ·Líder Técnico INSERT-UECE ·Agilista desde 2010 ·@hedlabel ·hedleygois@gmail.com
4. Agora sim...
5. Mas… o que é teste?
6. – Dicionário Aurélio “Averiguação do funcionamento de algo.”
7. Mas, como?
8. l “na unha” “print/alert/console“ Teste automatizado Teste unitário Teste de integração Teste de aceitação Test Driven Development Behaviour Driven Development Acceptance Test Driven Development Planilhas Checks Caixa Preta Caixa Branca Caixa Cinza etc… ! ! ! ! ! ! ! !
9. Mas...
10. Tá pronto! (falta só testar….)
11. Mas, vale a pena…
26. –Agile Manifesto “Continuous attention to technical excellence and good design enhances agility.”
27. Coisa de dev?
28. NÃO!
29. “Pair Testing"
30. –Agile Manifesto “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
31. public static int calculaSoma(int a, int b) { return 0; } ! public static void main(String args[]) { System.out.println(“A soma deve ser 4. E foi: “ + calculaSoma(2,2); }
32. Testes Automatizados ·Qualquer teste que rode sem intervenção humana(ou com pouca) ·Porque? Velocidade(mesmo nos de aceitação)! ·Teste de regressão! ·Feedback rápido e contínuo(Karma, Infinitest…!) ·Não garante qualidade de código! ·Não garante “Clean Code” ·Integração Contínua e Entrega Contínua
33. “Padrão" de Testes
34. Teste Unitário ·eXtreme Programming! ·Teste a menor porção de código possível ·Deve ser simples e conciso = Isolado = Desacoplado ·Rápida execução ·Devem ser poucos por classe
35. ! ! List(1, 2, 3, 4, 5) should contain oneOf (5, 7, 9) ! ! it("should pop values in last-in-first-out order") { val stack = new Stack[Int] stack.push(1) stack.push(2) assert(stack.pop() === 2) assert(stack.pop() === 1) }
36. Mocks ·Facilitar os testes ·Abstrair implementações complexas ·Mock !== Fake Object !== Stub ·Mock = Comportamento ·Legados!
37. @Mock private Gerenciador gerenciador; ! @Test public void NaoDeveExcluirCasoExistamDocumentosVinculados() { when(gerenciador.documentosDo(“fulano”)).thenReturn("existeDocumento"); when(gerenciadorSaidas.buscarSaidas()).thenCallRealMethod(); ! assertFalse(gerenciador.excluir("fulano")); }
38. Teste de Integração lParafraseando Bruno Maomeh e Matheus Fechine: ·Se conversa com o DB, não é teste unitário ·Se comunica pela rede, não é teste unitário ·Se ele toca no sistema de arquivos, não é teste unitário ·Se ele não pode rodar junto de outro teste, não é teste unitário ·(Possível)Porta de entrada para testes em legados
39. @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations= {"classpath:applicationContext-test.xml"}) @Transactional public class UsuarioServiceTest { ! @Autowired private UsuarioService usuarioService; ! @Test public void deveCarregarUsuarioJoao(){ Usuario usuario = usuarioService.carregaUm(usuarioJoao()); assertEquals(usuarioJoao(), usuario); }
40. Teste de Aceitação ·GUI testing ·Teste final de uma user story(ou similares) ·Lento, Custoso e Frágil ·Dev + Tester/Requisitos ·Caixa Preta
41. it('should add on service', function(){ element(by.model('service.identifier')).sendKeys('security'); element(by.model('service.function')).sendKeys('Security'); selectDropdownByNumber(element(by.id('serviceType')), 1); element(by.id('utilizationLevel')).sendKeys(protractor.Key.ENTER); element(by.id('btnAdd')).click(); services = element.all(by.repeater('row in renderedRows')); expect(services.count()).toEqual(QUANTITY_SERVICES + 1); });
42. TDD ·Testar !== TDD ·Baby Steps ·Rápido Feedback + Melhoria Contínua ·Design/Arquitetura de Código ·Regras de Negócio = “Pair Testing” === Compartilhamento de conhecimento
43. Fluxo TDD Não escrevo código novo enquanto um teste não quebrar
44. BDD ·Similar ao TDD, mas numa linguagem mais próxima do negócio lVantagens do TDD + Traz o business mais perto do desenvolvedor ·Compartilhamento de Conhecimento ·É a “evolução do TDD”
45. ! @Given("^Minha saudacao e \"([^\"]*)\"$") public void I_have_a_hello_app_with(String greeting) { hello = new Hello(greeting); } ! @When("^Eu executo minha aplicacao$") public void I_ask_it_to_say_hi() { hi = hello.sayHi(); } ! @Then("^Ela deveria responder com \"([^\"]*)\"$") public void it_should_answer_with(String expectedHi) { assertEquals(expectedHi, hi); }
48. ATDD ·Dev + QA/Tester/Requisitos/Business ·Especificações criadas durante a criação do backlog: Time + PO + Stakeholders(se necessário) ·Top-Down ou Bottom-Up? Não há consenso. ·Ponto de Vista do Usuário != Ponto de Vista do Código, logo TDD ! == ATDD
50. Mais importante é… O que NÃO TESTAR!
51. –Refactoring: Improving the Design of Existing Code, 1999 “The key is to test the areas that you are most worried about going wrong. That way you get the most benefit for your testing effort. It is better to write and run incomplete tests than not to run complete tests”
52. –Agile Manifesto “Simplicity--the art of maximizing the amount of work not done--is essential.”
53. “Novo” requisito =Novo Teste = Refatoração
54. –Agile Manifesto “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”
55. Por que nasceu legado? ·"Mais fácil re-escrever que refatorar" ·“Na minha máquina funciona!” ·“Funciona, só não sei porque…" ·Difícil de evoluir! Cadê a segurança? ·Nova feature === +10 Bugs(e que você só detecta em produção) ·Error prone!
56. Leituras Recomendadas
57. Livro de Cabeceira
58. Testes
59. Refactoring