TDD (Test-driven Development) как стиль разработки.
•Descargar como PPTX, PDF•
2 recomendaciones•1,370 vistas
Как превратить рутинное написание Unit тестов в увлекательный процесс? Как побороть страхи, что система не будет работать должным образом? Как уверенно решать самые сложные для себя задачи? Я расскажу как TDD поможет найти ответы на эти и другие вопросы. Наш сайт http://www.tuladev.net
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Destacado
Destacado (20)
Similar a TDD (Test-driven Development) как стиль разработки.
Similar a TDD (Test-driven Development) как стиль разработки. (20)
Más de Pavel Tsukanov
Más de Pavel Tsukanov (14)
TDD (Test-driven Development) как стиль разработки.
- 1. Киреев Артем Разработчик Codemasters Intl. est1908@gmail.com
- 2. I. Происхождение TDD II. Основные принципы TDD III. Мотивации использования TDD IV. TDD Best practices V. Пример TDD VI. TDD – FAQ
- 3. Каскадные Как ISO получится ГОСТ Низкоформализованные Высокоформализованные RUP XProgramming Scrum Канбан Итерационные
- 4. Customer Tests Collective Coding Ownership TDD Standart Whole Small Team Releases Pair Refactoring Programming Continuous Simple 40h Week Integration Design Planning Metaphor Game
- 5. Customer Tests Collective Coding Ownership TDD Standart Whole Small Team Releases Pair Refactoring Programming Continuous Simple 40h Week Integration Design Planning Metaphor Game
- 6. Простые программные решения Цель TDD: Тесты придающие уверенность в работе Всего 2 правила: 1. Пишем новый код, только тогда когда тест не сработал 2. Удаляем дублирование Мантра TDD Написать тест который не проходит RED Написать код, чтобы тест проходил REFACTOR GREEN Убрать дублирование
- 7. Добавляем тест Тесты прошли Запускаем все тесты Тесты не прошли Добавляем небольшие изменения Тесты не прошли Снова запускаем все тесты Рефакторинг Тесты прошли Тесты не прошли
- 8. Не писать лишнего кода Проектировать less coupled системы Возвращаться к коду Начинать разрабатывать не теряя время Темп разработки С первого раза (а значит быстрее) решать сложные задачи Контролировать стресс. Постоянно видеть прогресс. Исправлять ошибки на раннем этапе разработки
- 10. UnitTest – читаемый, простой, малосвязанный, быстрый Лучше много простых тестов, чем один сложный. Начинаем писать тест с «Assert» Сначала пишем самые простые тесты Список желаемых тестов на бумаге, не в коде и не в уме Тесты должны работать быстро Темп разработки Не пишем код, пока на него нет теста Пишем наиболее простой код, необходимый чтобы тест прошел Только что написанный тест должен падать (работает в 99%) После успешного прохождения теста - рефакторить Все тесты должны проходить перед написанием нового теста Рефакторинги и паттерны – друзья TDD
- 12. Сколько писать тестов? Можно ли начать использовать TDD прямо сейчас на текущем проекте? Можно ли использовать TDD для разработки крупномасштабных систем? Какие есть подходы cвязанные c TDD? Негативные стороны TDD …
- 13. Все проблемы UnitTest-ов Не поддерживаются IntelliSense like tools Тесты тоже требует рефакторингов. Темп разработки Сложно применить TDD на плохой код Тесты не гарантируют отсутствие ошибок
- 14. Не пишем код, пока на него нет теста Простые программные решения Список тестов на бумаге Покрытие тестами Refactor Less coupled modules Assert First Сначала простые тесты Уверенность в работе Идем к цели маленькими шажками
Notas del editor
- Существует множество методологий разработки ПО. Их можно характеризовать по 2-м параметрам.Речь пойдет о XPКаскадная методология также называемая «водопад» делит весь процесс разработки на несколько фаз, каждая включает в себя конкретный набор работ. Итеративная же разработка разбивает проект на итерация в каждой из которой выполняется почти все виды работ, от проектирования до внедрения и в конце каждой итерации мы можем видеть раюотающий продукт с нарастающей функциональностью.
- XP одна из гибких (Agile) методологих разработки ПО.Ее можно описать как 12 практик:Постоянное присутсвие заказчика,Команда находится рядом, в одной комнатеИгра в планированиеКороткие релизыСтандарты кодирования40-часовая рабочая неделяМетафорыПостоянная интеграцияКоллективное владение кодомПарное программированиеРефакторингПростой дизайнРазработка через тестирование
- TDD – одна из практик Экстремального программирования. Одним из первых ее последователей, как и всего XP был Кент Бекер.Он написал книжку по XP и другую по TDD.Использование TDD тесно связано и использованием других практик XP и позволяет нам не уходить от них в процессе разработки ПО.Никто не мешает использовать TDD отдельно.
- Test-DrivenDevelopment— разработка через тестирование.Буквально можно перевести как «разработка, ведомая тестами» или «разработкаисходя из тестов».
- Задачу следует разбивать на мельких шажки, на столько мелкие на сколько требуется для ее комфортного решения.3 В рамках T DD вы пишете только тот код, который необ-, ходим для срабатывания тестов, вы удаляете из него любое дублирование,значит, вы автоматически получаете код, который идеально адаптирован к' текущим требованиям и подготовлен к любым будущим пожеланиям.
- 1 TDD обязывает нас писать только нужный код – пишем только нужный код, ничего лишнего. Это один из принципов применяымый в XP. Потомучто код спроектированный на будущие, будет дня нас впоследствии обузой он будет тянуть ненужные связи и его нужно будет тоже рефакторить. А запланированная функциональность может вовсе не пригодиться или стать не акутальный в связи с измененными требованиями.2. Как известно хороший unit-test тот который не имеет зависимостей на внешние ресурсы (БД, Сеть, интрернет, файловая система), просто написан и быстро работает. Только при наборе таких тестов мы сможем эффективно применять ТДД.Мы пишем сначала тест, а потом код, значит не имеет никаких требования со стороны кода влияющих на дизайн теста.Поэтому мы можем в самом начале выбрать путь абстракции от внешний ресурсов. Не всегда правда оптимальный 3. Возвращаться к коду – TDD позволяет взглянуть на написанный код несколько раз. Вы можете держать в голове кучу задач которые должен выполнять код который вы напишите с первого раза. Или несколько раз будите возвращаться к нему с целью внести новые требования.не сразу с целью реализовать все возможное.4 Начинать разрабатывать не теряя время.Не имея большого опыта в проектирования систем, тяжело или невозможно сразу применить паттерныщиепримлимый дизайн которй будет соттветсвовть требованиям.Использую TDD мы разбиваем задачу на маленькие шажки (настолько маленькие насколько нужно) и постепенно адаптриуем с помощью рефакторингов и паттернов систему к каждому их требований.Это медленно? Я бы не сказал – в итоге мы получаем неплохо спроектированную систему полностью покрытую юнит тестами.Также с большой долей вероятности у нас нет риска переписывания системы с нуля. Так как мы движемся к цели маленькими шажками от теста к теста.5 С первого раза (а значит быстрее) решать сложные задачиБывает тяжело сразу прикинуть в голове как должен быть реализован тот или иной сложный алгоритм.Мы движемся к решению сложной задачи (алгоритма) маленькими шажками, настолько маленькими насколько это удобно нам. И постепенно адаптируем алгоритм ко всем нужным требованиям.6 Контролировать стрессДопустим у нас имеется крупная задача. Мы тратим неделю на ее проектировку и кодирования. Полученный результат мы может увидеть только спустя неделю. И начинается процесс поиска и справленияошибко, может быть даже нам придеться вернуться к самому началу, если выбранный дизайн будет тяжело В TDD мы уверенно движемся к цели мельники шажками. Результат очередного изменения коды мы видим моментально сразу после запуска всех тестов.Мы идем к цели успешно решаю маленькие задачи и чувствуем себя комфортно.
- 1 TDD обязывает нас писать только нужный код – пишем только нужный код, ничего лишнего. Это один из принципов применяымый в XP. Потомучто код спроектированный на будущие, будет дня нас впоследствии обузой он будет тянуть ненужные связи и его нужно будет тоже рефакторить. А запланированная функциональность может вовсе не пригодиться или стать не акутальный в связи с измененными требованиями.2. Как известно хороший unit-test тот который не имеет зависимостей на внешние ресурсы (БД, Сеть, интрернет, файловая система), просто написан и быстро работает. Только при наборе таких тестов мы сможем эффективно применять ТДД.Мы пишем сначала тест, а потом код, значит не имеет никаких требования со стороны кода влияющих на дизайн теста.Поэтому мы можем в самом начале выбрать путь абстракции от внешний ресурсов. Не всегда правда оптимальный 3. Возвращаться к коду – TDD позволяет взглянуть на написанный код несколько раз. Вы можете держать в голове кучу задач которые должен выполнять код который вы напишите с первого раза. Или несколько раз будите возвращаться к нему с целью внести новые требования.не сразу с целью реализовать все возможное.4 Начинать разрабатывать не теряя время.Не имея большого опыта в проектирования систем, тяжело или невозможно сразу применить паттерныщиепримлимый дизайн которй будет соттветсвовть требованиям.Использую TDD мы разбиваем задачу на маленькие шажки (настолько маленькие насколько нужно) и постепенно адаптриуем с помощью рефакторингов и паттернов систему к каждому их требований.Это медленно? Я бы не сказал – в итоге мы получаем неплохо спроектированную систему полностью покрытую юнит тестами.Также с большой долей вероятности у нас нет риска переписывания системы с нуля. Так как мы движемся к цели маленькими шажками от теста к теста.5 С первого раза (а значит быстрее) решать сложные задачиБывает тяжело сразу прикинуть в голове как должен быть реализован тот или иной сложный алгоритм.Мы движемся к решению сложной задачи (алгоритма) маленькими шажками, настолько маленькими насколько это удобно нам. И постепенно адаптируем алгоритм ко всем нужным требованиям.6 Контролировать стрессДопустим у нас имеется крупная задача. Мы тратим неделю на ее проектировку и кодирования. Полученный результат мы может увидеть только спустя неделю. И начинается процесс поиска и справленияошибко, может быть даже нам придеться вернуться к самому началу, если выбранный дизайн будет тяжело В TDD мы уверенно движемся к цели мельники шажками. Результат очередного изменения коды мы видим моментально сразу после запуска всех тестов.Мы идем к цели успешно решаю маленькие задачи и чувствуем себя комфортно.
- 3 Assert first - Начинаем писать тест со слова Assert. потом развиваем дальше.4 Я бы сказал не пишем код для реализации нового требования к системе если на него нет тестов
- Сколько писать тестов?"Пишите тесты до тех пор пока страх не превратиться в скуку." PhlipPlumlee. Я придерживаюсь того же мнения- Можно ли начать использорвать TDD прямо сейчас? Да можно на текущем проекте.Да. можно разрабытывать отдельные части и модули с помощью TDD,Можно ли использовать TDD для разработки крупномасштабных систем?ДаTDD будет там скорее выгоднее, потомучто вы получите модульную систему с покрытыми тестами бизнес функциямиКакие есть пути развития TDDATDDTDDD – Test Driven Database developmentBDD – Behaviour drivendeveolopment Следующим шагом, органично дополняющим эволюционировавший TDD является BDD — BehaviorDrivenDevelopment.Суть BDD — в описании системы архитектуры приложения в терминах эксперта предметной области, а не программиста, что позволяет ускорить процесс получения обратной связи и убрать традиционные языковые барьеры между создателями ПО и его пользователями.С помощью BDD тестировать систему (или, как сейчас принято говорить, описывать сценарии взаимодействия) может не только сам программист, пишущий код, но и PM, не разбирающийся в деталях реализации, но хорошо знающий систему с точки зрения пользователя. Для новичков BDD-скрипты — самый простой и натуральный пусть ознакомиться с документацией проекта.
- Все проблемы UnitTest-овМногопоточность, связанность с Не поддерживаются IntelliSenselike toolsТак как тест пишется на код которого нет, и поначалу даже не компилируется. То мы лишаемся поддержикиIntelliSenseТесты тоже требует рефакторингаПотеря времени при рефакторинге Сложно применить TDD на плохойкодДопустим вам нужно добавить бизнесу функцию, и вы хотите написать сначала тест.А ваш коллега написал плохой coupled код, который заязван на UI.Неэффективен на проектах, с минимальной бизнес логикой. UI tools
- Test-DrivenDevelopment— разработка через тестирование.Буквально можно перевести как «разработка, ведомая тестами» или «разработкаисходя из тестов».