bannerbannerbanner

Экстремальное программирование. Разработка через тестирование

Экстремальное программирование. Разработка через тестирование
ОтложитьЧитал
000
Скачать
Поделиться:

Возвращение знаменитого бестселлера. Изящный, гибкий и понятный код, который легко модифицировать, который корректно работает и который не подкидывает своим создателям неприятных сюрпризов. Неужели подобное возможно? Чтобы достичь цели, попробуйте тестировать программу еще до того, как она написана. Именно такая парадоксальная идея положена в основу методики TDD (Test-Driven-Development – разработка, основанная на тестировании). Бессмыслица? Не спешите делать скороспелые выводы. Рассматривая применение TDD на примере разработки реального программного кода, автор демонстрирует простоту и мощь этой методики. В книге приведены два программных проекта, целиком и полностью реализованных с использованием TDD. За рассмотрением примеров следует обширный каталог приемов работы в стиле TDD, а также паттернов и рефакторингов, имеющих отношение к TDD. Книга будет полезна для любого программиста, желающего повысить производительность своей работы и получить удовольствие от программирования.


В формате a4.pdf сохранен издательский макет.

Серия "Библиотека программиста (Питер)"

Полная версия

Отрывок

Видео

Лучшие рецензии на LiveLib
80из 100alexey-goloburdin

Кент Бек считается одним из основателей методологии TDD и поэтому мне хотелось познакомиться с его книгой о разработке через тестирование. До этого я читал разные материалы об автотестах и методиках тестирования, и хотелось познакомиться с первоисточником.Мои впечатления неоднозначны. Книга из трёх частей – в первой практика, чтобы показать, как происходит работа в TDD-стиле. Все это я уже где-то читал и мне не было интересно. Вторая часть – показать, как с TDD писать инструментарий для тестирования. Плохая идея, как по мне, причем автор сам говорит о ее сомнительности, приводя аналогию операции на собственном мозге. Зачем оно тогда в книге? Новички не знают о XUnit, JUnit и тп. А те, кто знает уже современный инструментарий, тем и читать это не сильно интересно как по мне. Третья часть – теория. Что-то из нее было интересно почитать, но часть про шаблоны проектирования тут непонятно зачем. Понять шаблоны из такого описания невозможно, а кто с шаблонами уже знаком, тому и не надо описывать это в десятый раз.При этом речь вообще тут идёт о модульном (юнит) тестировании, на котором автотесты не заканчиваются – есть ещё интеграционные, функциональные и тд, и сейчас, насколько я могу судить, разработку начинают с более высокоуровневого теста (например, теста конечного хттп-сервиса), и затем спускается разработка на юнит-тесты с реализацией этого хттп-сервиса, его бизнес-логики. Обо всем этом нет в книге.В целом, наверное, материал можно рассматривать как отправную точку для своего времени, когда это всё зарождалось. В послесловии Мартин Фаулер пишет, что «все эти мысли несколько сыроваты», «мы ещё не видим эту картину достаточно четко, однако мне кажется, что она постепенно становится все яснее и яснее».Кто пишет на питоне, могу порекомендовать небольшой цикл статей по TDD https://www.thedigitalcatonline.com/blog/2020/09/10/tdd-in-python-with-pytest-part-1/. Не знаю, упустите ли вы что-то глобальное, если вместо Кента Бека прочтете эти пять статей.Читается быстро, плотность информации в бОльшей части книги небольшая.Дальше буду читать по этой теме Персиваля с его «Python Разработка на основе тестирования».

100из 100anatoly

Открывает глаза на планирование проектов разработки ПО. Книга будет полезна любому руководителю проектов – много полезных идей.Активно использую идеи из книги: в работе и в личных проектах.

0из 100OrregoChield

Поскольку я не программист, мне книжка была интересна поскольку постольку, хотелось только разобраться, что же это за TDD такое, приобщиться, так сказать, к бест практисам.

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

Штош, основную идею я вроде как уяснила, но как приложить ее к своей повседневной практике – пока сообразить не получилось, как, впрочем, и есть ли вообще смысл примеряться.

Суть одной строкой вот в этой цитате:Красный – зеленый – рефакторинг – это мантра TDD.Ну то есть прикидываешь, чего тебе надо добиться, пишешь проверочный тест, потом пишешь какой угодно код, чтобы тест хоть как-то выполнился, потом шлифуешь полученное так, чтобы тест выполнялся и при этом код не дублировался. Начинаешь заново с другим кусочком логики. Автор разбирает это на разных примерах с кусочками кода, а в конце говорит о паттернах. В принципе, познавательно. Если когда-нибудь надумаю переметнуться в стан разработчиков, вероятно, вернусь к этой книге.

Оставить отзыв

Рейтинг@Mail.ru