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
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
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
480
Automated Testing: Getting it Right
skanev
1
110
From Novice to Expert
skanev
0
470
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
Event is what happens
moro
2
780
Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜
utakaha
2
560
AmebaブログはKMPから卒業します
kmars0605
0
190
月間100万人のサービス刷新で、 技術選定をHonoに振り切った話
yutobara
8
6.6k
ActionController meets Protocol Buffers
sorah
0
530
HTML-in-Canvasで作る未来のWeb UI表現
clockmaker
5
5.1k
Starting & Sustaining Code-Based E2E Testing for Non-Coding QA Teams( #jasstniigata )
teyamagu
PRO
1
1k
気持ちぃ〜角丸 Squircle
ryu1013
0
310
動作中のプログラムの中身をリアルタイムに覗く / Realtime Debugger for CSharp with Roslyn
prota
1
1.9k
Compiling a real-world CLI tool to native with Static Hermes
tmikov2023
0
120
ソニーのクラウド共通基盤の変遷とAI時代の開発スタイルに合わせた進化 / The Journey of Sony’s Common Cloud Platform and Its Evolution for AI-Native Development
kenjiyoneyama
0
270
SalesForceを内製化!? ~ HR事業を支える顧客管理基盤のインフラを大公開 ~
oku053
0
180
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
6.3k
Are puppies a ranking factor?
jonoalderson
2
4.1k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.7k
Mind Mapping
helmedeiros
1
400
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
370
Amusing Abliteration
ianozsvald
1
350
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
23k
The Curious Case for Waylosing
cassininazir
1
570
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.6k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
480
The Limits of Empathy - UXLibs8
cassininazir
2
720
Deep Space Network (abreviated)
tonyrice
0
370
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