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
0
490
За смъртта на TDD
Презентацията от PlovdivConf 2014
Stefan Kanev
May 17, 2014
Tweet
Share
More Decks by Stefan Kanev
See All by Stefan Kanev
Въведение в (Machine|Deep) Learning
skanev
0
73
GraphQL
skanev
0
360
Automated Testing: Getting it Right
skanev
1
48
From Novice to Expert
skanev
0
410
Inbetween Code and Profession
skanev
0
350
Clojure & ClojureScript
skanev
2
100
Extreme Programming
skanev
0
590
Python 0 2014
skanev
1
1.6k
Clojure 0 2014
skanev
0
360
Other Decks in Programming
See All in Programming
Vue SFCのtemplateでTypeScriptの型を活用しよう
tsukkee
3
1.2k
本編では話さない Zig の話
andpad
2
130
モジュラモノリス、その前に / Modular monolith, before that
euglena1215
8
750
書籍『LangChainとLangGraphによるRAG・AIエージェント[実践]入門』の紹介
os1ma
2
130
僕がつくった48個のWebサービス達
yusukebe
6
3.6k
自分だけの世界を創るクリエイティブコーディング / Creative Coding: Creating Your Own World
chobishiba
2
2.1k
4年間変わらなかった YOUTRUSTのアーキテクチャ
daiki1003
2
710
フロントエンドの現在地とこれから
koba04
10
4.7k
破壊せよ!データ破壊駆動で考えるドメインモデリング / data-destroy-driven
minodriven
4
430
Re:proS_案内資料
rect
0
210
急速に利用拡大を続ける飲食店向けサービスで 店内端末同士のローカル通信を追加設定なしで実現した話
whatasoda
0
150
Golang と Erlang
taiyow
7
1.8k
Featured
See All Featured
Side Projects
sachag
452
42k
How GitHub (no longer) Works
holman
311
140k
Building Better People: How to give real-time feedback that sticks.
wjessup
363
19k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
130k
Code Review Best Practice
trishagee
64
17k
Adopting Sorbet at Scale
ufuk
73
9k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
A designer walks into a library…
pauljervisheath
202
24k
[RailsConf 2023] Rails as a piece of cake
palkan
49
4.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.6k
For a Future-Friendly Web
brad_frost
174
9.4k
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