“Javascript também é
   código. Teste!”
Além dos bons motivos
já conhecidos
•   Diferenças entre navegadores
•   Complexidade nas interfaces
•   Volume de código
E porque o povo não testa?
Is paining
•   DOM
•   Interações do usuário
•   AJAX, animações
•   Múltiplos navegadores
•   ...
Falando em soluções!
Test Driven Development .
Cool!
•   Trata sobre Design
•   Foco no “como” e não no “o quê”
•   Pode ser unitário, funciona...
Test Driven Development.
Benefícios!
•   Falhas de design aparecem mais cedo
•   Fácil saber quando já cobrimos todos os
 ...
Para ajudar. Um zilhão de
ferramentas!
•   Testes unitários: qUnit, YUITest, JSUnit
•   BDD: Screw.Unit, JSpec, JSSpec
•  ...
qUnit.
Porque?
Pros
   • Mantido pelo time do jQuery

   • Testes assíncronos

   • Setup e TearDown


Cons
   • Variáveis...
pyccuracy/lettuce/cucumber.
Porque?
Pros
   • Interação entre widgets

   • Mais rápido escrever os testes

   • Fácil int...
chameleon
Porque?
Pros
   • Nós o mantemos

   • Fácil de usar

   • Integrado ao qUnit


Cons
   •  Faltam features
   • ...
Ainda sobre mocks!
Faz sentido criar um mock
quando o objeto:
•   gera resultados não deterministicos
•   tem estados difíceis de criar ou re...
O que esperar de uma
ferramenta de Mock?
•   Simular a chamada para um método
•   Adicionar expectativas
•   Validar se o ...
Integração Contínua e
múltiplos navegadores?
•   Selenium grid
•   Hanoi
•   Yeti
•   TestSwarm
•   JsTestDriver
Obrigado!


Felipe Silva @felipe_silva
Marcio Duarte @Maethorin
Upcoming SlideShare
Loading in …5
×

Front-end javascript unit testing and mock

2,234 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,234
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
19
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

  • Nenhuma mudança é pequena de fato; Permite refactor; Viabiliza integração contínua; Paz de espirito;
  • As interações com usuários são complexas, dependem de controlarmos eventos o tempo inteiro. Requisições que podem ser assincronas e ainda termos que ter uma URL em algum canto que funcione e retorne algo. Navegadores: o que funciona em um pode não funcionar em outro. Como integrar nossos testes em nosso CI?

  • Desenhar bem! E é disso que TDD trata: Design.
    Definir como seu código será usado. Interfaces com o mundo exterior. Isso não é o quê...
    Você pode fazer TDD tanto inside-out ou outside-in.
    Você ainda vai precisar criar mais testes para melhorar sua cobertura e ter a Paz de espírito
    Pq ver o teste quebrar? Pq implementar mais simples? Pq ver o teste passar? Pq refatorar?
  • O que vc idealizou pode não ser tão simples de consumir.
    O “como” mantém o foco no requisito e não no código em sí.
    Sabedoria popular... Economia de esforço... Carpem Diem... Próximo passo o mais curto possível
    É complexo, é chato, é desconhecido? Baby steps torna mais digerível...
    Já sabe o que quer. Economize o cérebro deixando a metodologia trabalhar pra você.
  • Muitas foram descontinuadas, outras tantas possuem documentação deficiente. (open source)
    YUITest é possível fazer testes funcionais básicos apenas.
    SYN, para auxiliaem testes funcionais.
  • Curva de aprendizado menor, comparado com os demais frameworks de teste unitário;
    Integração com inúmeras bibliotecas de mock;
    jqUnit: Surgiu para acabar com a bagunça de variáveis globais.
    Poucos asserts: equals, ok, same
    CODAR
  • Testes de ace



  • CODAR.


  • Front-end javascript unit testing and mock

    1. 1. “Javascript também é código. Teste!”
    2. 2. Além dos bons motivos já conhecidos • Diferenças entre navegadores • Complexidade nas interfaces • Volume de código
    3. 3. E porque o povo não testa? Is paining • DOM • Interações do usuário • AJAX, animações • Múltiplos navegadores • Integração continua
    4. 4. Falando em soluções!
    5. 5. Test Driven Development . Cool! • Trata sobre Design • Foco no “como” e não no “o quê” • Pode ser unitário, funcional e até BDD • Não substitui testes automatizados • Tem regras e é bom segui-las (pq?)
    6. 6. Test Driven Development. Benefícios! • Falhas de design aparecem mais cedo • Fácil saber quando já cobrimos todos os requisitos • Baby Steps • Bom quando não se sabe o que quer • Melhor ainda quando já se sabe o que quer
    7. 7. Para ajudar. Um zilhão de ferramentas! • Testes unitários: qUnit, YUITest, JSUnit • BDD: Screw.Unit, JSpec, JSSpec • Mock: qMock, Jack, Chameleon • Testes funcionais: YUITest (apenas o básico), Pyccuracy, Letuce, Cucumber
    8. 8. qUnit. Porque? Pros • Mantido pelo time do jQuery • Testes assíncronos • Setup e TearDown Cons • Variáveis globais pra tudo que é lado • Poucos asserts
    9. 9. pyccuracy/lettuce/cucumber. Porque? Pros • Interação entre widgets • Mais rápido escrever os testes • Fácil integrar ao CI Cons • Não é atômico
    10. 10. chameleon Porque? Pros • Nós o mantemos • Fácil de usar • Integrado ao qUnit Cons • Faltam features • Documentação de ciente
    11. 11. Ainda sobre mocks!
    12. 12. Faz sentido criar um mock quando o objeto: • gera resultados não deterministicos • tem estados difíceis de criar ou reproduzir • ainda não existe ou pode ter o comportamento alterado • é necessário adicionar informações ou métodos, exclusivamente para os testes • ou simplesmente quer abstrair o resultado
    13. 13. O que esperar de uma ferramenta de Mock? • Simular a chamada para um método • Adicionar expectativas • Validar se o esperado foi chamado • Informar, com clareza, falhas na expectativa • Deixa o teste legível, claro
    14. 14. Integração Contínua e múltiplos navegadores? • Selenium grid • Hanoi • Yeti • TestSwarm • JsTestDriver
    15. 15. Obrigado! Felipe Silva @felipe_silva Marcio Duarte @Maethorin

    ×