Доклад на третьем митапе сообщества http://tver.io о том, почему не может существовать TDD в классическом виде, какие возможности преподносят нам использование суррогатных объектов и как отнестись к подходу скептично и использовать лучшие практики, которые метод разработки через тестирование привнес в инженерию ПО.

1. Методы разработки
качественного и
"чистого" кода
Новиков Иван

2. Новиков Иван
http://jonnynovikov.com/
@jonny

3. Моя позиция может не
совпадать с позицией
компаний, в которых я
работаю

4. Кто я?

5. Novikov Ivan
CTO at & Backend engineer atAmiforus ozon.travel
http://jonnynovikov.com/

6. Agenda
TDD
РЕФАКТОРИНГ
АРХИТЕКТУРА
ПРОЦЕССЫ
ПРИМЕРЫ НА C#
ДИАГНОЗ И ЗАКЛЮЧЕНИЕ
Q&A

7. TDD?

8. TDD...
будем дальше считать академическим видом
программирования
SUT, SUD, .... почему все-таки TDD - огромный
вклад в развитие инженерии в целом?

9. РЕФАКТОРИНГ
не должен изменять семантику
должен улучшать качество

10. РЕФАКТОРИНГ
не панацея
стоимость, необходимость

11. АРХИТЕКТУРА

12. Несовершенная архитектура
непредвиденные изменения
существенные изменения

13. REFACTOR!
непредвиденные изменения
REBUILD!
существенные изменения

14. РЕФАКТОРИНГ ТРЕБУЕТ
АНАЛИЗА
Рефактори СВОЁ!
хлам от рефакторинга останется хламом (GIGO)
никакое его количество не спасет дефектную
архитектуру

15. Rebuild
Удачи!

16. ПРОЦЕССЫ

17. РАЗРАБОТКА, управляемая
тестами
полноценный метод разработки ПО

18. Test First Development
create test
modify: code the simple thing
refactor

19. "Make it work. Make it right. Make it
fast."
Kent Beck

20. Test Driven Development
create test
check test is failed
modify: code the simple thing
ensure test is passed
continuous refactor (unify)

21. "Лондонская школа TDD"
моки как средство унификации проектирования
ПО

22. Реальность

23. Code example

24. О спецификациях
(MSpec)

25. Основные принципы
Простота (KISS)
"Чистый" код
Не делай то, что сейчас не используешь (YAGNI)

26. Attention

27. Будьте скептиком
Разработку, управляемую тестами стоит
попробовать
Моки необходимо использовать
ТОЛЬКО там, где они действительно нужны
и еще...

28. Где меня обманули
тесты - это не все, что нужно для спецификации
ПО
тест более специфичен, чем user story
поиски общих правил, нет рецепта генерации
спецификации по тестам

29. Почему все-таки классная
штука?
каждый новый код должен сопровождаться
тестами
экстремальный вариант хороший способ
заставить себя сделать это

30. Немного кода

31. Почему многие
ВООБЩЕ не пишут
тесты?
- "Зачем проверять только состояния?"
- "Это отнимет всё время"
- "Их невозможно поддерживать"

32. Почему ПИШУТ и даже
разрабатывают через
тесты?
У них есть рецепт, который другие не знают?

33. Проблемы заглушек

34. Isolation Framework
Используя NSubstitute
https://github.com/nsubstitute/NSubstitute
код с предыдущего слайда превращается в

35. Mocking Framework
Moq https://github.com/Moq/moq4

36. С блэкджеком и...
девочками
IoC + Nancy https://github.com/NancyFx/Nancy

37. О необходимости
тестирования

38. Тесты - тоже искусство
Selenium WebDriver http://seleniumhq.org

39. Вырастающая
сложность

40. Поддержка

41. Проектирование и
программирование -
виды человеческой деятельности;
стоит об этом забыть – и все пропало.
Бьярн Страуструп, 1991

42. Что начать читать завтра?
Ironies of Automation, 1983
Test-Driven development: By example (Kent Beck,
2003)
Исскуство автономного тестирования (Рой
Ошервуд):
илирусская english
&
Что посмотреть вместо
сериала?
Norwegian Developers Conference (NDC)

43. Q&A
Презентация тут: http://j.mp/quality-evolve