$30 off During Our Annual Pro Sale. View Details »

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

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

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

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