Commits

Konstantine Rybnikov  committed 45eafa0

some uapycon tdd input

  • Participants
  • Parent commits 1516ee4

Comments (0)

Files changed (1)

File source/launchpad/2012-08-06-uapycon-tdd/index.html

 
 ---
 
-# Agenda
+class: center, middle
 
-1. Introduction
-2. Deep-dive
-3. ...
+# Константин Рыбников
+
+Twitter: @ko_bx. Email: k-bx@k-bx.com.
+
+Веб-сайт: http://redhotchilipython.com
 
 ---
 
-# Introduction
+class: center, middle
+
+# Зачем тестировать? Я и сам могу написать 2 линии кода.
+
+<!--
+Черт возьми, да я могу и 10 линий кода написать. И ДВАДЦАТЬ!
+-->
+
+---
+
+# Robert Martin "What killed smalltalk could kill ruby":
+
+<!--
+RailsConf 09
+
+- почему же никто не следует правилу бой-скаутов? потому что писать
+  чистый код -- сложно!
+- i’m not touching that
+- как только вы редактируете код -- вы им владеете (ответственность)
+- компилятор не бьет по рукам (слишком легко превратить код в беспорядок)
+- прелесть питона: за огромной чашкой кофе можно сотворить небольшой
+  проект. мы всё еще хотим писать на питоне без компиляторов.
+-->
+
+Правило бой-скаутов: оставляйте место после себя чище, чем оно было.
+
+---
+
+# 3 правила tdd
+
+<!--
+Программист находится в вечном цикле, постоянно подтверждающем
+корректность его кода.
+
+Люди вечно ищут отмазки от TDD (я лично сначала тоже искал и думал что
+TDD -- бред), доходит до своих выдумок "полу-TDD" и "недо-TDD"
+(прим. Cogniance Express), но главное -- понять суть.
+-->
+
+- You are not allowed to write any production code unless it is to
+  make a failing unit test pass.
+- You are not allowed to write any more of a unit test than is
+  sufficient to fail; and compilation failures are failures.
+- You are not allowed to write any more production code than is
+  sufficient to pass the one failing unit test.
+
+---
+
+# Почему я начал тестировать
+
+<!--
+
+Процесс разработки в Пром.уа:
+
+- центральная огромная БД. запускаешь относительно нужной (если есть)
+  (регистрация новой компании, если надо etc.)
+- подымаешь веб-сервер с нужным конфигом (если есть)
+- цикл: заполнить нужные данные, кликанье (заполнить формы и т.д.),
+  получить exception и понять где ошибся
+- провести код-ревью, убедив на словах, что фича работает (- разве
+  должно работать? - да точно говорю, работает!)
+- цикл: переброс тикета туда-сюда с QA-командой (ужасный процесс с
+  психологической т.з.)
+
+Еще минусы:
+
+- невозможность работать без сети
+- поиск тестовых данных (каждый раз, даже во время разработки)
+- alt+tab hell => плюс были мысли, что на питоне написать тест не
+  должно быть сложнее, чем руками заполнить БД нужными значениями
+
+По поводу декларирования качества кода: во время интервью сказали
+"практикуется высокое качество продуктов и кода" => теперь это
+проблема интервьювера убедиться, что вы саму задачу тоже решать
+будете.
+-->
+
+Начало:
+
+- опыт с предыдущей(-их) работы
+- возможность написать проект с нуля -- интересно попробовать
+- ответственность за баги перекладывается на плечи не написавшего
+  тесты
+- в компании декларируется высокое качество кода
+- API-центричное приложение (удачи в ручном форировании
+  HTTP-заголовков)
+
+---
+
+<!--
+Бонус ко всему прочему.
+-->
+
+# Как результат
+
+- в стрессовой ситуации (стартап) нет времени на code review => код
+  остаётся на должном уровне качества
+- очень сложная бизнес-логика и валидация форм легко поддаётся
+  "доработке"
+- повышение качества кода (рефакторинг за час до релиза)
+- объяснение фичи другому программисту практически 1-к-1 превращается
+  в описание функционального теста
+- разработчики в других странах
+- даже после сопротивлений и отмазок, другие разработчики начинают
+  писать (сами) тесты
+
+---
+
+class: center, middle
+
+# Ближе к практике
+
+---
+
+<!--
+- размытость терминологии, я предпочитаю вот такую (иногда не
+  "интеграционные" а DbTest)
+-->
+
+# Бред терминологии
+
+Тесты бывают:
+
+- функциональные
+- интеграционные
+- юнит-тесты
+
+---
+
+# Вы всегда выбираете либо "проще" либо "быстрее"
+
+---
+
+# Gary Bernhardt "Fast test / Slow test":
+
+<!--
+PyCon US
+-->
+
+Причины тестировать:
+
+- повысить стабильность (regression)
+- отсутствие страха (refactoring)
+- простой код проще тестировать (design)
 
     </textarea>
     <div id="slideshow"></div>
   </body>
-</html>
+</html>