Огромное спасибо автору за эту книгу: мастхэв имхо! Книга не просто про тестирование, но про архитектуру к кучей полезной практической информации и идей. Отлично сочетается с такими великими книгами от дядюшки Боба, как Чистый код и Чистая архитектура.
Наверное, единственная книга на русском языке, целиком посвященная юнит- (в основном) и интеграционному (в меньшей мере) тестированию. В книге совсем нет информации о применении фреймворков тестирования, только систематизация различных подходов, классификации и оценки юнит-тестов. Я, например, про существование лондонской и классической/детройтской школ тестирования не знал, как и про их отличия. Подробно рассматриваются вопросы работы с моками, стабами и зависимостями. В общем, соотношение объем/полезная информация на, казалось бы, простую тему - очень высокое.
Прекрасная книга, спасибо автору за труд! Очень многое становиться понятным. Такая книга обязательна к прочтению. С методологической точки зрения все описано прекрасно, чисто и понятно. Однако, есть некоторые моменты, которые бы я хотел подсветить. Автор явно выделяет детройтскую школу как лучший подход для юнит тестов, но сам факт долгого параллельного существования обоих школ говорит, что нельзя однозначно выбрать лучшую. Иначе бы уже давно осталось только одна. Лондонская школа предлагает, на мой взгляд, гораздо более понятный, четкий и стандартизируемый подход к написанию юнит-тестов. При таком подходе всегда можно оценить степень качества тестов и их покрытия, проще проводить код ревью, проще объяснять новичкам и мидлам как писать тесты и разбивать код на юниты. При подходе когда юнитом считается кусок поведения начинают возникать разногласия, также кусок поведения сложнее понимать так как в нем возникает иерархия. Также гораздо проще рефаторить существующий монолитный код через откалывание от него кусков функций и введения интерфейсов, которые затем успешно мокаются/стабаются. За всю свое карьеру программиста 10+ лет я не наблюдал большой проблемы хрупкости тестов, так как никто не переписывает существующий код каждый день и не меняет контракты и особенно это касается разработки в энтерпрайзе где юзер кейсы далеко не так очевидный по тому что за чистую там во многих местах и пользователей то толком нет, а автоматизируются процессы за кадром. Однако в командах нацеленных больше на б2с решения с высокой нагрузкой и быстро меняющимися требованиями и костяком сеньоров конечно детройтская школа подойдет гораздо лучше. В любом случае вам огромное спасибо Владимир!
Не исчерпывающая, но хорошая книга про то, как стоит писать тесты. Речь там идет не только юнит тестах, но и интеграционных, e2e.
Вообще это одна из немногих книг по тестированию, где просто рассказывается о том как тестировать, что тестировать и тд. Никаких TDD. Просто о тестировании.
Не могу сказать, что она перевернула мое сознание. Может быть не хватило опыта, ну или читал не очень вдумчиво. Но. Советов много и они полезные. Большинство из них я стал применять на практике.
Книга небольшая, читается просто. Не пугайтесь примеров на шарпах, если какой-то язык знаете, проблем разобраться в листингах не будет.
Это книга, которую я могу смело рекомендовать всем разработчикам. Мало кто пишет тесты, еще меньше тех, кто пишет хорошие тесты — книга как раз об этом, как писать эффективные юнит и интеграционные тесты, какими свойствами они обладают и тд. Отличный материал.
Для лучшего усвоения стоит читать после знакомства с гексагональной/чистой архитектурой, так как качественное тестирование и качественный код связаны, книга рассказывает и о теме архитектуры, но в целом уже подразумевая, что читатель с этой темой знаком. Можно порекомендовать прочесть Чистую архитектуру Мартина и возможно Паттерны разработки на Python Персиваля предварительно, чтобы лучше понять архитектурные темы, затронутые в книге Хорикова. Хотя, возможно, и так всё понятно будет:)
Материал — огонь!
Книга с большим количеством вредных советов, которую я ни в коем случае не порекомендую новичкам. Автор слишком зациклен на классической школе юнит тестирования, что ведет к плачевным результатам:
- отрицание использования мокирования в тестах бизнес логики, сервисов и т.д. не ведет к повышению их устойчивости к рефакторингу (как пишет сам автор), а создает ком из неизведанных проблем с тестами и окружением при любом неосторожном изменении в дебрях имплементации. Тесты становятся полностью беззащитны перед лицом рефакторинга, опять таки делая их хрупкими в виду недостатка изоляции от реализации.
- использование приватных внепроцессных зависимостей в тесте (!) с призывом "ну, раз будет быстро, то нормально" :\
Сомневаюсь, что кто-нибудь получит десятилетний опыт разработки тестов после прочтения данной книги.
Recenzje książki «Принципы юнит-тестирования (pdf + epub)», 6 opinie