Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Testes em JS Como Você Nunca Viu Antes
Search
Lucas Fernandes da Costa
November 26, 2016
Programming
0
330
Testes em JS Como Você Nunca Viu Antes
My slides for the presentation in JSDay Recife 2017, which happened at Nov. 26th, 2016.
Lucas Fernandes da Costa
November 26, 2016
Tweet
Share
More Decks by Lucas Fernandes da Costa
See All by Lucas Fernandes da Costa
Types, tests, and why flat-earthers are bad at QA (HolyJS)
lucasfcosta
0
31
What did we Learn with JavaScript Fatigue? (FrontMania)
lucasfcosta
1
47
How I'm still not using GUIs in 2019
lucasfcosta
0
59
Programming with Birds - There is a Bluebird in My Talk That Wants to Get Out (LambdAle 2018)
lucasfcosta
0
110
What can we learn with JavaScript Fatigue? - FrontEnd United
lucasfcosta
2
200
What Can We Learn With JavaScript Fatigue? - The Conf SP
lucasfcosta
0
81
What Can We Learn With JavaScript Fatigue? - NebraskaJS
lucasfcosta
2
110
JavaScript Behind the Scenes: Meta Programming (FluentConf 2017)
lucasfcosta
0
130
Testes em JavaScript: A Maneira Correta
lucasfcosta
0
66
Other Decks in Programming
See All in Programming
아직도 SOLID 를 '글'로만 알고 계신가요?
sh1mj1
0
340
PHPer's Guide to Daemon Crafting Taming and Summoning
uzulla
2
570
RCPと宣言型ポリシーについてのお話し
kokitamura
2
130
Devin入門 〜月500ドルから始まるAIチームメイトとの開発生活〜 / Introduction Devin 〜Development With AI Teammates〜
rkaga
6
2.4k
Cloudflare Pagesのサイトを NotebookLMから読みやすくする Cloudflare Meet-up Tokyo Vol.7
xiombatsg
0
110
爆速スッキリ! Rspack 移行の成果と道のり - Muddy Web #11
dora1998
0
130
Gunma.web #55
tinykitten
0
120
もう一人で悩まない! 個の知見をチームの知見にする3つの習慣と工夫 / Into team knowledge.
honyanya
3
500
Firebase Dynamic Linksの代替手段を自作する / Create your own Firebase Dynamic Links alternative
kubode
0
130
バックエンドNode.js × フロントエンドDeno で開発して得られた知見
ayame113
4
1.2k
もっと大きなデータを送りませんか? エラーがゴロゴロ出るようなデータです
sublimer
0
180
RecSys2024 参加報告
unonao
1
170
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
42
7.3k
How to Ace a Technical Interview
jacobian
276
23k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
How GitHub (no longer) Works
holman
314
140k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
12
1.4k
Code Review Best Practice
trishagee
67
18k
Into the Great Unknown - MozCon
thekraken
35
1.7k
Faster Mobile Websites
deanohume
306
31k
A better future with KSS
kneath
238
17k
The Invisible Side of Design
smashingmag
299
50k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
480
Transcript
Testes em JavaScript Como você nunca viu antes @lfernandescosta @lucasfcosta
lucasfcosta.com
‣ Sistemas de Informação @UFSC ‣ FullStack Developer @MyTapp ‣
ChaiJS Core Maintainer ‣ Apaixonado por Open Source Quem sou eu?
‣ Sistemas de Informação @UFSC ‣ FullStack Developer @MyTapp ‣
ChaiJS Core Maintainer ‣ Apaixonado por Open Source Quem sou eu? Internacionalmente conhecido por causar prejuízo em buffet livre de sushi
Quem sou eu? @lfernandescosta @lucasfcosta lucasfcosta.com
Por que testar?
Qualidade do código
Ok, todo mundo sabe disso Qualidade do código
Agilidade Melhores estimativas Mais feedback Mais rápido
< Redução de custos
QA + Trabalho Proativo - Trabalho Reativo
Validação ‣ Feedback rápido ‣ Prova que o código está
correto OS DOIS LADOS DO TDD TDD
Validação Unde omnis iste. ‣ Feedback rápido ‣ Prova que
o código está correto OS DOIS LADOS DO TDD Especificação TDD ‣ Demonstra o que aquela peça deve fazer ‣ Demonstra os resultados esperados
Validação Unde omnis iste. ‣ Feedback rápido ‣ Prova que
o código está correto OS DOIS LADOS DO TDD Especificação TDD ‣ Demonstra o que aquela peça deve fazer ‣ Demonstra os resultados esperados O teste serve como spec
Requisitos mais claros Primeiro você pensa
Requisitos mais claros Primeiro você pensa Depois você coda
Test Driven Design
Program to an interface, not an implementation
Program to an interface, not an implementation Menos acoplamento
"TDD Should be Fun" - James Sinclair
Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS.
Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS. ‣
Feedback positivo constante e rápido
Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS. ‣
Feedback positivo constante e rápido ‣ Reduz o medo, prova que você está no caminho certo
Feedback Loop Metas de Longo Prazo Recompensas Rápidas VS. ‣
Feedback positivo constante e rápido ‣ Você sabe que está no caminho certo DIVERSÃO
Bons motivos para testar:
Bons motivos para testar: 1 Agilidade
Bons motivos para testar: 1 Agilidade 2 Redução de custos
Bons motivos para testar: 1 Agilidade 2 3 Redução de
custos QA Proativo
Bons motivos para testar: 1 Agilidade 2 4 3 Redução
de custos Especificação QA Proativo
Bons motivos para testar: 1 Agilidade 2 4 5 3
Redução de custos Especificação QA Proativo Test Driven Design
Bons motivos para testar: 1 Agilidade 2 4 5 6
3 Redução de custos Especificação QA Proativo Diversão Test Driven Design
Como escrever bons testes?
Só automatizar não é o suficiente
Automated crap is still crap
Você não pode provar que seu software funciona
Você não pode provar que seu software funciona Você só
pode provar que ele não funciona
Desenvolvimento em pequenos passos
Desenvolvimento em pequenos passos Mais segurança
Passos do tamanho da sua segurança
Passos do tamanho da sua segurança
"Qual tamanho devem ter meus testes?"
"Qual tamanho devem ter meus testes?"
"Qual tamanho devem ter meus testes?" O necessário
"Qual tamanho devem ter meus testes?" O necessário Somente o
necessário
"Qual tamanho devem ter meus testes?" O necessário Somente o
necessário O extraordinário é demais
Isolamento Teste unitário testa apenas uma unidade (função)
Isolamento Teste unitário testa apenas uma unidade (função) Quando algo
falhar, sabemos pontualmente o que falhou
Isolamento
Independência Um teste depende apenas de uma “peça”
Independência Um teste depende apenas de uma “peça” Um defeito
causa falha em um teste
Independência Stubs
Independência
Foco Um teste tem apenas um objetivo
Foco Um teste tem apenas um objetivo Faça o mínimo
de asserções por teste
Foco Evite testes "frouxos"
Foco Evite testes "frouxos"
Foco Evite testes "frouxos" Quantos testes passam nisso?
Foco
Desacoplamento O teste não depende da implementação
Desacoplamento O teste não depende da implementação Program to an
interface, not an implementation
Desacoplamento Você paga por testes em manutenção
Para fazer bons testes:
Para fazer bons testes: 1 Isolamento
Para fazer bons testes: 1 Isolamento 2 Independência
Para fazer bons testes: 1 Isolamento 2 3 Independência Foco
Para fazer bons testes: 1 Isolamento 2 3 4 Independência
Foco Desacoplamento
Estou no caminho certo?
Testes que falham são testes que produzem informações
Testes que falham são testes que produzem informações Se arrisque
Code coverage é bom
Code coverage é bom Mas não é tudo
100% Code Coverage function incrementaIndice(arr, i) ➡ Soma 1 ao
valor de índices já existentes ➡ Se o valor naquele índice é indefinido ele passa a ser 1
100% Code Coverage
100% Code Coverage Asserções
100% Code Coverage Asserções Possibilidades de entrada
Medindo Coverage
Medindo Coverage
Cross-platform
Cross-platform Diferentes implementações
Cross-platform Diferentes implementações Diferentes features suportadas
Cross-platform Tenha fallbacks
O ecossistema parece grande…
O ecossistema parece grande…
O ecossistema parece grande… Mas é simples
The UNIX Philosophy
Mais possibilidades The UNIX Philosophy
Mais possibilidades Aprendizado gradual The UNIX Philosophy
Recapitulando:
Recapitulando: 1 Mocha
Recapitulando: 1 2 Mocha Chai
Recapitulando: 1 2 3 Mocha Chai Sinon
Recapitulando: 1 2 4 3 Mocha Chai Sinon Istanbul
Recapitulando: 1 2 4 5 3 Mocha Chai Sinon Istanbul
Karma
Valeu, Recife!
Valeu, Recife! Free software is great software