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
За смъртта на TDD
Search
Stefan Kanev
May 17, 2014
Programming
640
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
За смъртта на TDD
Презентацията от PlovdivConf 2014
Stefan Kanev
May 17, 2014
More Decks by Stefan Kanev
See All by Stefan Kanev
Въведение в (Machine|Deep) Learning
skanev
0
110
GraphQL
skanev
0
460
Automated Testing: Getting it Right
skanev
1
94
From Novice to Expert
skanev
0
450
Inbetween Code and Profession
skanev
0
450
Clojure & ClojureScript
skanev
2
140
Extreme Programming
skanev
0
820
Python 0 2014
skanev
1
1.8k
Clojure 0 2014
skanev
0
400
Other Decks in Programming
See All in Programming
AIを活用したE2Eテスト実装効率化のあゆみ / ebisu-mobile-14-kotetu
kotetuco
0
130
鹿野さんに聞く!『TypeScriptコードレシピ集』で磨く実践力
tonkotsuboy_com
4
840
Observability in Practice:Grafana 與 Edge Device SRE 的那些事
blueswen
0
180
1B+ /day規模のログを管理する技術
broadleaf
0
110
ローカルLLMを使ってB2Bサービスを作っていての学び
yaotti
0
220
Vue × Nuxt × Oxc どこまで使える?実運用の現在地
andpad
0
300
キャリア迷子上等 ─ "ない道"は自分で作ればいい
16bitidol
3
2.3k
代数的データ型って何が嬉しいの? #frontend_phpcon_do
kajitack
8
3.8k
AI 輔助遺留系統現代化的經驗分享
jame2408
1
1k
AIで効率化できた業務・日常
ochtum
0
150
「AIで開発し、AIを届ける」をEvalでつなぐ 〜AIネイティブに始めるプロダクト開発の実践〜 / Connecting "Develop with AI, deliver AI" with Eval
rkaga
4
5.4k
生成AI時代にこそ効くGo | Why Go Works in the Age of Generative AI
mom0tomo
8
3.3k
Featured
See All Featured
Site-Speed That Sticks
csswizardry
13
1.2k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
150
How GitHub (no longer) Works
holman
316
150k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
540
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
260
Being A Developer After 40
akosma
91
590k
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
170
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
220
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
220
Transcript
За смъртта на TDD Стефан Кънев http://skanev.com/ @skanev PlovdivConf 17
май 2014 Пловдив
DHH (David Heinemeier Hansson)
None
None
None
None
None
None
None
Кратката версия: греши
Риторика в две стъпки
Test-driven
Представя малка част за цялата картинка 1.
нишови практики
Казва: въобще не са добра идея Има предвид: не му
вършат работа за Basecamp 2.
Q.E.D.
все пак: повдига валидни притеснения
Диалог
None
Дългата версия: …
GOOS Mocks Test-induced design damage Hexagonal Architecture TDD
x y z
Здравейте, аз съм Стефан
Twitter @skanev GitHub @skanev Blog skanev.com
1. test-first vs. test-after 2. hexagonal architecture 3. mocking &
isolation 4. валидните притеснения План 1. 2. 3. 4.
TEST-FIRST TEST-AFTER 1.
None
“Ако имах повече време, щях да напиша по-кратко писмо” !
— Паскал, Твен, Франклин, т.н.
“The essence of writing is rewriting”
При четимия код е същото: ревизирането е ключа е към
разбираемостта
None
ВХОД ИЗХОД
една история
None
None
1. Зареди си кода 2. Изтрий всичко от базата 3.
Добави в една таблица 4. Добави в другата 5. Свържи ги Създай .rb файл, в който:
пускане грешка промяна
Същата идея: малки стъпки с честа обратна връзка
кога не работи?
ВХОД ИЗХОД
Кога не правя test-first: 1. Когато не пиша тестове 2.
Когато не съм много неуверен в интерфейса
2. Hexagonal Architecture
hexagonal architecture
шестоъгълна архитектура
Как са направим бизнес логиката независима от GUI-то/базата/framework-а?
Controller Model Database View Бизнес логика
Бизнес логика Order Transaction User <<interface>> Controller View <<interface>> Model
Database
None
Основен trade-off: добавяме индирекция за да спечелим независимост
клъстеризация по-сложно, но по-сигурно
None
Подходящо за определени ситуации, но не е универсално
прост пример с код
Disclaimer твърде просто за ⬡
class EmployeesController < ApplicationController! def create! @employee = Employee.new(params[:employee])! !
if @employee.save! redirect_to @employee, notice: "#{@employee.name} created"! else! render :new! end! end! end!
class EmployeesController < ApplicationController! def create! CreateEmployee.run(params[:employee], {! success: ->
(employee) {! redirect_to employee, notice: “#{employee.name} created"! },! failure: -> (employee) {! @employee = employee! render :new! }! })! end! end
моят опит
Дава добри решения за малки части (5%) от приложението
Добро попълнение за торбата с трикове, но далеч не и
универсален инструмент
Mocks 3.
оплетена терминология
mocks, stubs, doubles, у-а умишлено мърляв
Controller Model Database MailChimp Twitter API View Internal
Тестваме взаимодействието с колабораторите, а не резултата от страничния им
ефект
mocks + test-first = GOOS
GOOS, London School
пример
Controller Model Database 1. Създай потребител 2. Извикай контролера 3.
Провери новото име в базата без mock-ове
Controller Model с mock-ове user = mock('User')! User.stub find:
user! user.should_receive(:update) .with(name: 'Jon')! post :create, name: ‘Jon'!
два проблема
1. “вложени mock-ове”
mock, който връща mock, който връща mock, който връща mock
проблем в приложението
структурирано програмиране
if {! if {! if {! ...! } else {!
if {! if {! ...! } else {! ...! }! }! }! } else {! ...! }! } else {! ...! }
Опитните mockist-и приемат това като симптом. Или има твърде
много coupling, т.е. проблем в дизайна… …или в този случай е приемливо и тестваме в интеграция.
2. “пречи на refactoring”
“Искам да refactor-на кода, но тестовете ми пречат”. ! Странно,
обикновено е обратното.
ВХОД ИЗХОД
Работи добре при стабилни интерфейси. Не е подходящо за изменчиви
такива.
Изводи 4.
Извод №1 ! “Ако не правиш TDD, не си професионалист”
е лъжа
Извод №1.5 ! “Ако не правиш _____, не си професионалист”
е лъжа
Извод №2 ! TDD се научава и обяснява трудно. Трябва
да се прави внимателно.
Извод №3 ! There is no silver bullet. Контекста е
цар.
None
None