Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
TDD IRL
Search
delucas
September 09, 2014
Technology
130
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
TDD IRL
Charla de TDD dada en la UTN F.R. Rosario, el día 09/09/2014
delucas
September 09, 2014
More Decks by delucas
See All by delucas
TBD - Too Busy Disorder
delucas
0
580
Gamification
delucas
1
130
Pedacitos de rubí
delucas
0
84
¿Aún no usás git y GitHub?
delucas
0
61
Desarrollo de Aplicaciones Móviles - Maestría en Informática
delucas
0
150
You already git started. Now... what?
delucas
3
150
TDD IRL reloaded
delucas
0
100
Adaptación de una plataforma de e-learning a nuevos entornos
delucas
0
270
Introducción wecode.io
delucas
0
77
Other Decks in Technology
See All in Technology
株式会社シーエーシー エンジニア向け会社紹介資料
cac
0
57k
Reactの設計論
uhyo
24
13k
現場で役立つ技術負債の効果的な返済方法
masuda220
PRO
8
4.1k
新機種発売前に見直そう!端末移行で再ログインが要るアプリ・要らないアプリは何が違うのか 〜シームレスに再開できる設計と実装〜
zozotech
PRO
0
200
研究開発部の紹介 / Sansan R&D Profile
sansan33
PRO
5
25k
AIエージェントの自己改善をどう設計するか / How to Design Self-Improvement for AI Agents
22mi
23
15k
空間オーディオで過去の 自分(ゴースト)と競うランニング 〜HealthKitのルートを足音に変える実装〜
nao_randd
0
220
【技術的負債conf】事業成長に伴う技術的負債の説明責任とAIによるモニタリング、認知的負債について
i35_267
2
1.6k
Genieを崇めよ
kameitomohiro
0
130
synctest時代のhttptest Go 1.27で変わるHTTPサーバテストの裏側 / go conference2026 synctest and httptest
budougumi0617
1
3k
え、こんなに早く改修できるの?──新人エンジニアとスクラムマスターの2人が語る、AI×アジャイル開発の現場
ysasago
0
120
10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み
10xinc
0
1.9k
Featured
See All Featured
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.6k
The SEO Collaboration Effect
kristinabergwall1
1
560
Build your cross-platform service in a week with App Engine
jlugia
234
19k
First, design no harm
axbom
PRO
2
1.3k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
440
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.6k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
490
Designing Powerful Visuals for Engaging Learning
tmiket
1
550
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
510
GraphQLとの向き合い方2022年版
quramy
50
15k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
880
Transcript
#tdd @wecodeio @luke_ar
Expectativas • 1:30 horas • 27 diapositivas • 1 demostración
en vivo* • código simple, en Java * “en vivo”, significa que puede fallar :)
¿Testing?
None
None
None
None
@Test public void prueba(){ assertEquals(5, sumar(2, 3)); }
@Test public void prueba(){ assertEquals(5, sumar(2, 3)); } sumar() assertEquals
2 3 ? 5
Test Driven Development
@Test public void prueba(){ assertEquals(5, sumar(2, 3)); }
@Test public void prueba(){ assertEquals(5, sumar(2, 3)); }
@Test public void prueba(){ assertEquals(5, sumar(2, 3)); }
@Test public void prueba(){ assertEquals(5, sumar(2, 3)); }
El Mantra
El Mantra mínimo código nueva prueba mejoras de diseño
demostración factores primos
¿Dónde está la magia? • Ciclos cortos • No es
sólo sobre las pruebas • Pruebas → diseño
Reglas de oro • Nunca se escribe una nueva funcionalidad
si hay algún test que falla. • Nunca se escribe código si no hay un test que evidencie su ausencia. • No se debe escribir más código del necesario para hacer pasar la prueba.
Refactoring • Cambiar estructura sin cambiar comportamiento. • Remueve duplicación.
• Vuelve el código más simple. • Vuelve el código más legible. • Se debe aplicar tanto al código productivo como a las pruebas.
¿Por qué no le gusta a la industria? • Tiempos
• Tiempos • Tiempos • Tiempos
TDD no es hace magia • No deriva arquitectura: deriva
diseño local • Se necesita una visión de arquitectura, aunque se valide con TDD • No es necesario ser miope
Consejos • Siempre tener una lista junto al teclado para
anotar los casos que se nos ocurran extemporáneamente. • Practicar con pequeños ejemplos reales. • Practicar con problemas conocidos.
El secreto “A medida que los tests se vuelven más
específicos, el código se vuelve más genérico”
Recursos • TDD by example, de Kent Beck http://amzn.to/1k24MZ7 •
Roman Numerals Kata, de Jim Weirich http://youtu.be/983zk0eqYLY • http://codekata.com/ • https://github.com/garora/TDD-Katas
¿Preguntas?
Gracias :) @wecodeio @luke_ar