Upgrade to Pro — share decks privately, control downloads, hide ads and more …

За смъртта на TDD

За смъртта на TDD

Презентацията от PlovdivConf 2014

5ca07e641fada5a88a09277c45bd7c1b?s=128

Stefan Kanev

May 17, 2014
Tweet

More Decks by Stefan Kanev

Other Decks in Programming

Transcript

  1. За смъртта на TDD Стефан Кънев http://skanev.com/ @skanev PlovdivConf 17

    май 2014 Пловдив
  2. DHH (David Heinemeier Hansson)

  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. None
  10. Кратката версия: греши

  11. Риторика в две стъпки

  12. Test-driven

  13. Представя малка част за цялата картинка 1.

  14. нишови практики

  15. Казва: въобще не са добра идея Има предвид: не му

    вършат работа за Basecamp 2.
  16. Q.E.D.

  17. все пак: повдига валидни притеснения

  18. Диалог

  19. None
  20. Дългата версия: …

  21. GOOS Mocks Test-induced design damage Hexagonal Architecture TDD

  22. x y z

  23. Здравейте, аз съм Стефан

  24. Twitter @skanev GitHub @skanev Blog skanev.com

  25. 1. test-first vs. test-after 2. hexagonal architecture 3. mocking &

    isolation 4. валидните притеснения План 1. 2. 3. 4.
  26. TEST-FIRST TEST-AFTER 1.

  27. None
  28. “Ако имах повече време, щях да напиша по-кратко писмо” !

    — Паскал, Твен, Франклин, т.н.
  29. “The essence of writing is rewriting”

  30. При четимия код е същото: ревизирането е ключа е към

    разбираемостта
  31. None
  32. ВХОД ИЗХОД

  33. една история

  34. None
  35. None
  36. 1. Зареди си кода 2. Изтрий всичко от базата 3.

    Добави в една таблица 4. Добави в другата 5. Свържи ги Създай .rb файл, в който:
  37. пускане грешка промяна

  38. Същата идея: малки стъпки с честа обратна връзка

  39. кога не работи?

  40. ВХОД ИЗХОД

  41. Кога не правя test-first:
 1. Когато не пиша тестове 2.

    Когато не съм много неуверен в интерфейса
  42. 2. Hexagonal Architecture

  43. hexagonal architecture

  44. шестоъгълна архитектура

  45. Как са направим бизнес логиката независима от GUI-то/базата/framework-а?

  46. Controller Model Database View Бизнес логика

  47. Бизнес логика Order Transaction User <<interface>> Controller View <<interface>> Model

    Database
  48. None
  49. Основен trade-off: добавяме индирекция за да спечелим независимост

  50. клъстеризация по-сложно, но по-сигурно

  51. None
  52. Подходящо за определени ситуации, но не е универсално

  53. прост пример с код

  54. Disclaimer твърде просто за ⬡

  55. 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!
  56. 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
  57. моят опит

  58. Дава добри решения за малки части (5%) от приложението

  59. Добро попълнение за торбата с трикове, но далеч не и

    универсален инструмент
  60. Mocks 3.

  61. оплетена терминология

  62. mocks, stubs, doubles, у-а умишлено мърляв

  63. Controller Model Database MailChimp Twitter API View Internal

  64. Тестваме взаимодействието с колабораторите, а не резултата от страничния им

    ефект
  65. mocks + test-first = GOOS

  66. GOOS, London School

  67. пример

  68. Controller Model Database 1. Създай потребител 2. Извикай контролера 3.

    Провери новото име в базата без mock-ове
  69. Controller Model с mock-ове user = mock('User')! 
 User.stub find:

    user! 
 user.should_receive(:update)
 .with(name: 'Jon')! 
 
 
 post :create, name: ‘Jon'!
  70. два проблема

  71. 1. “вложени mock-ове”

  72. mock, който връща mock, който връща mock, който връща mock

  73. проблем в приложението

  74. структурирано програмиране

  75. if {! if {! if {! ...! } else {!

    if {! if {! ...! } else {! ...! }! }! }! } else {! ...! }! } else {! ...! }
  76. Опитните mockist-и приемат това като симптом. 
 Или има твърде

    много coupling, т.е. проблем в дизайна… 
 …или в този случай е приемливо и тестваме в интеграция.
  77. 2. “пречи на refactoring”

  78. “Искам да refactor-на кода, но тестовете ми пречат”. ! Странно,

    обикновено е обратното.
  79. ВХОД ИЗХОД

  80. Работи добре при стабилни интерфейси. Не е подходящо за изменчиви

    такива.
  81. Изводи 4.

  82. Извод №1 ! “Ако не правиш TDD, не си професионалист”

    е лъжа
  83. Извод №1.5 ! “Ако не правиш _____, не си професионалист”

    е лъжа
  84. Извод №2 ! TDD се научава и обяснява трудно. Трябва

    да се прави внимателно.
  85. Извод №3 ! There is no silver bullet. Контекста е

    цар.
  86. None
  87. None