O documento discute a importância dos testes no desenvolvimento de software, mencionando diferentes tipos de testes como teste unitário, de integração e de aceitação. Também aborda técnicas como TDD, BDD e ATDD que utilizam os testes para guiar o projeto e refatoração do código.

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. “Averiguação do funcionamento de algo.”
– Dicionário Aurélio

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. “Continuous attention to technical excellence
and good design enhances agility.”
–Agile Manifesto

27. Coisa de dev?

28. NÃO!

29. “Pair Testing"

30. “The most efficient and effective method of
conveying information to and within a
development
team is face-to-face conversation.”
–Agile Manifesto

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. “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”
–Refactoring: Improving the Design of Existing Code, 1999

52. “Simplicity--the art of maximizing the amount
of work not done--is essential.”
–Agile Manifesto

53. “Novo” requisito
=Novo Teste
= Refatoração

54. “Welcome changing requirements, even late in
development. Agile processes harness change
for
the customer's competitive advantage.”
–Agile Manifesto

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