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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Stefan Kanev
May 17, 2014
Programming
650
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
470
Automated Testing: Getting it Right
skanev
1
100
From Novice to Expert
skanev
0
460
Inbetween Code and Profession
skanev
0
460
Clojure & ClojureScript
skanev
2
140
Extreme Programming
skanev
0
830
Python 0 2014
skanev
1
1.8k
Clojure 0 2014
skanev
0
410
Other Decks in Programming
See All in Programming
XHTMLが残したもの
yosuke_furukawa
PRO
1
380
FastAPI の並行処理モデルを完全に理解する
hoto17296
9
3.7k
Kiroで創り、AgentCoreで繋ぐ!AWSで実践する「AI-DLC」から「AIエージェント統合」までの最新地図
licux
2
260
Hello, Hiroshima Geospatial Data! — Exploring DoboX with Python
ra0kley
0
160
コンパウンドプロダクト開発のためのローカルプロセスマネージャー再発明 #layerxgo
izumin5210
0
620
変化を抱擁するドキュメントの作り方 - ビジネスルール駆動開発がもたらす、コードとの新しい関係
ioki
2
100
ソフトウェアエンジニアにとっての生成AI - 特性を知って使い倒す / generative ai for software enginner
kishida
7
2.3k
Deep dive into the select statement (GopherCon UK)
jespino
0
170
Swift愛好会100回記念 第1回を振り返る
jollyjoester
0
110
異なる設計思想のフレームワークを経験して得た学び
amekuhideki
2
1.5k
まだ間に合う!今年の夏こそSchemeのマクロ展開器を完全理解!
omasanori
0
620
{ Android | Kotlin } Gradle Plugin in 2026
ryunen344
1
270
Featured
See All Featured
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
510
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
The browser strikes back
jonoalderson
0
1.6k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
320
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
370
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6.1k
How to Think Like a Performance Engineer
csswizardry
28
2.8k
Chasing Engaging Ingredients in Design
codingconduct
0
300
Paper Plane (Part 1)
katiecoart
PRO
1
10k
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