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

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

Жанры

Рейтинг LiveLib

4,3

191 оценка

5
50%
4
39%
3
9%
2
2%
1
0%

Ваша оценка

Прочитали 197Хотят прочитать 434

Рецензии

Аноним18 июля 2023 г.
Кент Бек считается одним из основателей методологии TDD и поэтому мне хотелось познакомиться с его книгой о разработке через тестирование. До этого я читал разные материалы об автотестах и методиках тестирования, и хотелось познакомиться с первоисточником.

Мои впечатления неоднозначны. Книга из трёх частей — в первой практика, чтобы показать, как происходит работа в TDD-стиле. Все это я уже где-то читал и мне не было интересно. Вторая часть — показать, как с TDD писать инструментарий для тестирования. Плохая идея, как по мне, причем автор сам говорит о ее сомнительности, приводя аналогию операции на собственном мозге. Зачем оно тогда в книге? Новички не знают о XUnit, JUnit и тп. А те, кто знает уже современный инструментарий, тем и читать это не сильно интересно как по мне. Третья часть — теория. Что-то из нее было интересно почитать, но часть про шаблоны проектирования тут непонятно зачем. Понять шаблоны из такого описания невозможно, а кто с шаблонами уже знаком, тому и не надо описывать это в десятый раз.

При этом речь вообще тут идёт о модульном (юнит) тестировании, на котором автотесты не заканчиваются — есть ещё интеграционные, функциональные и тд, и сейчас, насколько я могу судить, разработку начинают с более высокоуровневого теста (например, теста конечного хттп-сервиса), и затем спускается разработка на юнит-тесты с реализацией этого хттп-сервиса, его бизнес-логики. Обо всем этом нет в книге.

В целом, наверное, материал можно рассматривать как отправную точку для своего времени, когда это всё зарождалось. В послесловии Мартин Фаулер пишет, что «все эти мысли несколько сыроваты», «мы ещё не видим эту картину достаточно четко, однако мне кажется, что она постепенно становится все яснее и яснее».

Кто пишет на питоне, могу порекомендовать небольшой цикл статей по TDD https://www.thedigitalcatonline.com/blog/2020/09/10/tdd-in-python-with-pytest-part-1/. Не знаю, упустите ли вы что-то глобальное, если вместо Кента Бека прочтете эти пять статей.

Читается быстро, плотность информации в бОльшей части книги небольшая.

Дальше буду читать по этой теме Персиваля с его «Python Разработка на основе тестирования».
Читать далее
5
1,3K
Аноним24 февраля 2024 г.
Чистый код, который работает
Поскольку я не программист, мне книжка была интересна поскольку постольку, хотелось только разобраться, что же это за TDD такое, приобщиться, так сказать, к бест практисам.
Принципы изложены уже в предисловии, так что можно было дальше не читать, но мне обычно тяжело бросать начатые книги, да и хотелось разбора понагляднее, чтобы понять, а есть ли где-то в этой концепции место проектировщику и может ли проектировщик что-то для себя извлечь.
Штош, основную идею я вроде как уяснила, но как приложить ее к своей повседневной практике - пока сообразить не получилось, как, впрочем, и есть ли вообще смысл примеряться.
Суть одной строкой вот в этой цитате:

Красный - зеленый - рефакторинг - это мантра TDD.
Ну то есть прикидываешь, чего тебе надо добиться, пишешь проверочный тест, потом пишешь какой угодно код, чтобы тест хоть как-то выполнился, потом шлифуешь полученное так, чтобы тест выполнялся и при этом код не дублировался. Начинаешь заново с другим кусочком логики. Автор разбирает это на разных примерах с кусочками кода, а в конце говорит о паттернах. В принципе, познавательно. Если когда-нибудь надумаю переметнуться в стан разработчиков, вероятно, вернусь к этой книге.
Читать далее
4
299
Аноним27 февраля 2007 г.
Открывает глаза на планирование проектов разработки ПО. Книга будет полезна любому руководителю проектов - много полезных идей.
Активно использую идеи из книги: в работе и в личных проектах.
4
432

Все рецензии

Цитаты

Аноним22 июля 2018 г.
Прежде чем что-либо менять в коде, вы должны написать все тесты, которые кажутся вам необходимыми. Если этого не сделать, рано или поздно, выполняя рефакторинг, вы чего-нибудь поломаете. Код перестанет работать так, как должен. Вы потратите кучу времени на поиск ошибки и сформируете предубеждение против рефакторинга. Если подобный инцидент повторится, вы можете вообще перестать делать рефакторинг. Дизайн начнет деградировать. Вас уволят с работы. От вас уйдет ваша любимая собака. Вы перестанете мыться и чистить зубы. У вас начнется кариес. Чтобы сохранить зубы здоровыми, всегда сначала пишите тесты и только после этого выполняйте рефакторинг.
Читать далее
2
394
Аноним23 ноября 2021 г.
Sacrificing quality is not effective as a means of control.
1
285
Аноним23 ноября 2021 г.
When you don't know what to do though, risking failure can be the shortest, surest road to success.
1
110