Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
За смъртта на TDD
Stefan Kanev
May 17, 2014
Programming
0
190
За смъртта на TDD
Презентацията от PlovdivConf 2014
Stefan Kanev
May 17, 2014
Tweet
Share
More Decks by Stefan Kanev
See All by Stefan Kanev
GraphQL
skanev
0
180
Automated Testing: Getting it Right
skanev
1
38
From Novice to Expert
skanev
0
370
Inbetween Code and Profession
skanev
0
220
Clojure & ClojureScript
skanev
2
80
Extreme Programming
skanev
0
230
Python 0 2014
skanev
1
1.5k
Clojure 0 2014
skanev
0
350
Garbage Collection
skanev
0
180
Other Decks in Programming
See All in Programming
GraphQL+KMM開発でわかったこと / What we learned from GraphQL+KMM development
kubode
0
120
C言語でメモリ管理を考えた話
hkawai
0
190
Let's make a contract: the art of designing a Java API
mariofusco
0
160
2022 FrontEnd Training
mixi_engineers
1
280
Milestoner
bkuhlmann
1
200
The future of trust stores in Python
sethmlarson
0
180
확장 가능한 테라폼 코드 관리 (Scalable Terraform Code Management)
posquit0
1
310
UI State Modeling 어떤게 좋을까?
laco2951
1
220
Swift Concurrencyによる安全で快適な非同期処理
tattn
2
310
既存のプロジェクトにKMMを導入するための対応策
martysuzuki
2
300
スモールチームがAmazon Cognitoでコスパよく作るサービス間連携認証
tacke_jp
2
340
iOSアプリの技術選択2022
tattn
6
2.4k
Featured
See All Featured
Design by the Numbers
sachag
271
17k
Learning to Love Humans: Emotional Interface Design
aarron
261
37k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_i
21
14k
Scaling GitHub
holman
451
140k
Rebuilding a faster, lazier Slack
samanthasiow
62
7.2k
Faster Mobile Websites
deanohume
294
28k
Why You Should Never Use an ORM
jnunemaker
PRO
47
5.5k
Making Projects Easy
brettharned
98
4.3k
Documentation Writing (for coders)
carmenhchung
48
2.5k
What's in a price? How to price your products and services
michaelherold
229
9.3k
How GitHub Uses GitHub to Build GitHub
holman
465
280k
Side Projects
sachag
449
37k
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