Source

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

<!DOCTYPE html>
<html>
  <head>
    <title>It's just too easy to make a mess</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    <script src="remark-0.4.2.min.js" type="text/javascript"></script>
    <style type="text/css" media="screen">
      /* Slideshow styles */
      html, body {
        font-family: Ubuntu;
      }
    </style>
  </head>
  <body>
    <textarea id="source">

class: center, middle

# It's just too easy to make a mess

---

class: center, middle

# Константин Рыбников

Twitter: @ko_bx. Email: k-bx@k-bx.com.

Веб-сайт: http://redhotchilipython.com

---

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)

---

class: center, middle

# Вопросы?

    </textarea>
    <div id="slideshow"></div>
  </body>
</html>