Commits

Konstantine Rybnikov committed a87a626

ok, looks finished

Comments (0)

Files changed (4)

Add a comment to this file

source/launchpad/2012-08-06-uapycon-tdd/arch.odg

Binary file added.

Add a comment to this file

source/launchpad/2012-08-06-uapycon-tdd/arch.png

Added
New image

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

 # 3 правила tdd
 
 <!--
-Попытка формализировать практику тестирования (почти компиляция).
+TDD -- это попытка формализировать практику тестирования (почти
+компиляция).
 
 Программист находится в вечном цикле, постоянно подтверждающем
 корректность его кода.
 
 <!--
 
-## - опыт с предыдущей(-их) работы
+## - опыт с предыдущих работ
 
 - огромная центральная БД. запускаешь относительно нужной (если есть)
   (регистрация новой компании, если надо etc.)
 ## - ответственность за баги
 
 - не хотелось привязываться к проекту
-- хотелось честно тестировать, получая за это награду
+- хотелось честно тестировать, получая награду за честность (перед
+  собой)
 
 ## - в компании декларируется высокое качество кода
 
-Мне просто не оставили выбора. Во время интервью сказали "практикуется
-высокое качество продуктов и кода" => теперь это проблема интервьювера
-убедиться, что вы саму задачу тоже решать будете.
+В конце концов, мне просто не оставили выбора. Во время интервью
+сказали "практикуется высокое качество продуктов и кода" => теперь это
+проблема интервьювера убедиться, что вы саму задачу тоже решать
+будете.
 
 -->
 
-- опыт с предыдущей(-их) работы
+- опыт с предыдущих работ
 - возможность написать проект с нуля -- интересно попробовать
 - ответственность за баги перекладывается на плечи не написавшего
   тесты (а не на сломавшего код своим коммитом)
 Бонус ко всему прочему.
 -->
 
-- в стрессовой ситуации (стартап) нет времени на code review => код
-  остаётся на должном уровне качества
+- в стрессовой ситуации (стартап) нет времени на code review =>
+  качество остаётся на должном уровне
 - очень сложная бизнес-логика и валидация форм легко поддаётся
   "доработке"
-- повышение качества кода (рефакторинг за час до релиза -- не грызёт
-  технический долг)
+- повышение качества кода (рефакторинг за час до релиза, либо в "вечно
+  стабильной ветке" -- не грызёт технический долг)
 - объяснение фичи другому программисту практически 1-к-1 превращается
   в описание функционального теста
 - разработчики в других странах
 PyCon US
 
 - слайд-подготовка к терминологии и разделению по слоям
-- очевидно, что тестирование следует разбивать на слои
+- стаёт понятно, что тестирование следует разбивать на слои
 -->
 
 Причины тестировать:
 
 ## - интеграционные:
 
-- для локальных багов или очень сложной бизнес-логики / выборки
+- самые "естественные", и самые ненужные
+- для сложной бизнес-логики / выборки
 - локальный кусок кода, ограниченый с одной стороны (БД остаётся)
-- хорошо подходят для бизнес-логики
 
 ## юнит-тесты
 
 - имеют мощь компилятора, требуют много времени
+- быстрые
 - отсутствует работа с БД и сетью
-- быстрые
 - отображают вашу архитектуру
 - в вебе никто не пишет юнит-тестов, потому что никто не умеет дружить
   с сайд-эффектами и поддающимся тесту дизайном
 - относится ко всем видам тестов.
 -->
 
-# В написании тестов вы всегда выбираете либо "проще" либо "быстрее"
+# При написании тестов вы всегда выбираете либо "проще" либо "быстрее"
 
 ---
 
 
 <!--
 - (вкратце разберем пример)
-- что такое фикстуры и в дополнение к ним -- фабрики (factory_boy)
-- фабрики умеют .create() и .build()
-- фабрики -- гарантия быстрого создания модели
+    <strike>
+    - что такое фикстуры и в дополнение к ним -- фабрики (factory_boy)
+    - фабрики умеют .create() и .build()
+    - фабрики -- гарантия быстрого создания модели
+    </strike>
 - ВСЁ! неужели это сложнее, чем ручное тестирование фичи?
 - относительно медленный, зато понятно как писать
 - работая над API-centric приложением действительно видишь
 
 <!--
 - ну уж парсить HTML точно не надо
+-->
+
+---
+
+# DON'T PANIC
+
+<!--
 - все веб-приложения должны строиться вокруг "API", даже если никакого
   API не существует
 - нужно менять (строить) архитектуру, в которой будет понятие "view model"
 - из которой рендеринг шаблона -- тупая подстановка данных
 -->
 
----
-
-*[TODO]* картинка с архитектурой
+<img src="arch.png">
 
 ---
 
 # Как выглядит юнит
 
 <!--
-- посмотрим, как выгядит юнит в питоне
+- посмотрим, как выглядит юнит в питоне
 - не важно, лезет ли `bar` в БД, это всё равно сайд-эффект
-- вызов функции -- это прежде поиск функции в словаре модуля
 - как нам "подменить" `bar`, `baz` и `select`?
 -->
 
 
 <!--
 - для "ослабления" графа зависимостей используют DI
-- техника, в которой присутствует небоходимость как в джаве, так и в питоне
+- техника, в которой присутствует необходимость как в джаве, так и в питоне
 -->
 
 ---
 
+# DI -- проблема
+
 <!--
 - общая техника, для ослабления зависимости как между сущностями, так
   и модулями
 - модуль (юнит) house нельзя протестировать, не создав kitchen
 -->
 
-# DI -- проблема
-
     .python
     class House(object):
         def __init__(self):
 - тестируемым дизайном считается внедрение DI для того, чтоб модели
   оставались "листьями" графа зависимостей
 - логика "сборки" зависимостей отделяется от логики элементов сборки
-- НО КАКОЙ ЖЕ ЭТО КОШМАР. неужели для `bar`, `baz` и `query` нужно
-  создать по классу?
+- НО КАКОЙ ЖЕ ЭТО КОШМАР. неужели для `foo`, `bar`, `baz` и `query`
+  нужно создать по объекту?
 -->
 
     .python
 
 <!--
 - НЕТ!
+- вызов функции -- это прежде поиск функции в словаре модуля
 -->
 
 <img src="unit.png">
     .python
     import mock
     class TestFoo(BaseTestCase):
-        @patch("path.to.module.query", return_value=0)
-        @patch("path.to.module.baz", return_value=0)
-        @patch("path.to.module.bar", return_value=0)
+        @mock.patch("path.to.module.query", return_value=0)
+        @mock.patch("path.to.module.baz", return_value=0)
+        @mock.patch("path.to.module.bar", return_value=0)
         def test_should_return_0(self, bar_mock, baz_mock,
                                  query_mock):
              self.assertEquals(foo(0), 0)
 # Я могу замокать практически всё -- но вы не хотите этого видеть
 
 <!--
+- пишите тестируемый код, оставьте модели "лёгкими"
 - держите отдельно модели, бизнес-логику, конструирование и выборку
 - за модели, занимающиеся BL-вещами бить по рукам
 -->
     .python
     class MyModel(models.Model):
         def save(self, *args, **kw):
-            user = Users.objects.get(pk=10)
-            user.username = "I REGRET NOTHING"
-            user.save()
+            post = Post(title="I REGRET NOTHING")
+            post.save()
             return super(MyModel, self).save(*args, **kw)
 
 ---
 
 # Mockstar
 
+http://mockstar.readthedocs.org
+
 ---
 
 # Mockstar -- declarative mocking
 
 <!--
 - обычно _test-файл -- для одного модуля (ppatch)
-- autospec=True
+- класс для одного юнита
 - одно объявление сайд-эффектов для юнита (на все тесты)
 - можно добавлять возвращаемые по-умолчанию значения в side_effects
-- наконец, удобный доступ по `se.`
+- мелочи: autospec=True, удобный доступ по `se.`
 -->
 
     .python
-    import mockstar
-    ppatch = mockstar.prefixed_p("app.module.under.test",
-                                 autospec=True)
+    from mockstar import prefixed_p
+    ppatch = prefixed_p("app.module.under.test",
+                        autospec=True)
     class TestFoo(BaseTestCase):
         @ppatch('bar')
         @ppatch('baz')
 <!--
 - на любых уровнях
 - язык компактный и уютный
-- всё можно замокать
 -->
 
 ---
 
 class: center, middle
 
-# Культура
+# В заключение
 
 <!--
-David Cramer -- DjangoCon 2012
+David Cramer (sentry, disqus) -- DjangoCon 2012
 
 - в целом о докладе Крамэра -- мало интересного, как всегда показал
   тонну крутых тулз которые сам и написал, рассказал как всё покрыто
-  тестами, запускающимися в кластере. Но главная мысль гениальна:
-  главное -- культура (тестирования + код ревью)
+  тестами, запускающимися в кластере.
+- Вывод перевесил весь доклад -- культура (тестирования + код ревью)
+- Мой вывод: без тестирования никуда.
 -->
 
 ---
 
 class: center, middle
 
-# Вопросы?
+# Константин Рыбников
+
+Вопросы?
+
+---
+
+class: center, middle
+
+p.s.: загляните в исходник, если нужны доп. заметки
 
     </textarea>
     <div id="slideshow"></div>
Add a comment to this file

source/launchpad/2012-08-06-uapycon-tdd/unit.odg

Binary file modified.

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.