Шаблоны тестирования xUnit. Рефакторинг кода тестов

Martin Fowler Signature Book

by Gerard Meszaros

В книге "Шаблоны тестирования xUnit: рефакторинг кода тестов" показано, как применять принципы разработки программного обеспечения, в частности шаблоны проектирования, инкапсуляцию, исключение повторений и описательные имена, к написанию кода тестов. В части I рассматриваются теоретические основы методов разработки тестов и описываются концепции шаблонов и "запахов" тестов (признаков существующей проблемы). В частях II и III приводится каталог шаблонов проектирования тестов, "запахов" и других средств обеспечения большей прозрачности кода тестов. Кроме этого, в части III сделана попытка обобщить и привести к единому знаменателю терминологию тестовых двойников и подставных объектов, а также рассмотрены некоторые принципы их применения при проектировании как тестов, так и самого программного обеспечения.
Книга "Шаблоны тестирования xUnit: рефакторинг кода тестов" ориентирована на разработчиков программного обеспечения, практикующих гибкие процессы разработки. В основном здесь рассматриваются примеры для существующих реализаций инфраструктуры xUnit, но затронуты и более новые инфраструктуры тестирования на основе данных.

Genres: Programming, Technology, Software, Computer Science, Technical, Nonfiction, Reference

832 pages, Hardcover

First published May 1, 2003

Reviews

[Gleb Sevruk · Rating 1 out of 5]

I started with some interesting reading - but this was only Preface by Martin Fowler. I stopped reading at 200-th page because it gets too repetitive and makes no sense (just a catalogue with generic programming practices)

If you want to learn testing - I would recommend (in order):
Michael Feathers "Working Effectively with Legacy Code" (explains WHY to write test and how to achieve it)
Roy Osherove "The Art of Unit Testing"
Mark Seemann "Dependency Injection in .NET"

These guys knows what they are writing and how to convey material efficiently

[Tom Panning · Rating 3 out of 5]

This is a really good 300 page book in 800+ pages. Trying to teach myself unit testing, without a more experienced mentor helping me, I ran into a lot of cases where the suggestions in normal unit testing books and guides didn't seem to work. This book had good solutions for many of those problems.

Unfortunately, this book is incredibly repetitive with an unbelievable amount of duplicated content. It was to the point where I could read a new chapter, and for several pages I would swear that I must have already read it because it was so familiar. And when I wanted to look up something I remembered from the book, it was so hard to find it because the same topic is covered in so many places. It's not just that a topic is mentioned in several places and then really discussed in one place. I think Meszaros wanted the first part of the book to be a quick intro, and then the back of the book to be the encyclopedia reference with the full information. But the intros include 80% of the content in the reference section. And just as bad, I think Meszaros broke out the patterns too finely because many of them spend several paragraphs talking about other related patterns. Imagine if the GoF had made the Model, the View, and the Controller three separate patterns, but in each of the three patterns talked about how they fit together, and you'll get an idea.

This book has some great content in a packaging that made me almost give up on it so many times. So it's not junk, but I would consider it a book of last resorts. If you have a unit testing question and can't find the answer anywhere else, try looking in this book.

[Lazysmokier · Rating 3 out of 5]

Эта книга была написана автором в тесном сотрудничестве с Капитаном Очевидность. Вдвоем они руководствовались принципом "лишь повторенное трижды есть истина". Как результат книга полна воды, среди которой очень сложно отыскать крупицы полезной информации. Практически каждое словосочетание в книге (даже если оно самоочевидно) выделено курсивом и предполагает за собой Паттерн. В итоге некоторые Предложения В Книге представляют собой Типографическое Месиво от которого бы известный Отечественный дизайнер С фамилией Лебедев плакал бы Кровавыми Слезами.

Самым полезной частью в книге является введение, которое демонстрирует удачный рефакторинг существующего теста и раскрывает примерно половину содержания книги. Чуть менее содержательна первая часть (примерно до 200-й страницы) в ней (неоднократно) раскрывается все остальное. Оставшиеся страницы нужно читать выборочно, только в том случае если название паттерна почему-то наводит на подозрение что здесь еще осталось что-то неизведанное.

Читать рекомендуется позитивно настроенным терпеливым людям, которые во что бы то ни стало намерены прочитать эту книгу. Даже при этом, для экономии времени, не стоит читать книгу дальше первой части.

[Marshall · Rating 2 out of 5]

This book makes me feel like this practice of cataloguing software patterns is getting out of hand. It started with Design Patterns, a brilliant book that catalogued 9 common software design patterns. It wasn't intended to be exhaustive, just a handful of some of the most useful patterns. Then other books started cataloguing other patterns, in various realms of software. This book catalogues patterns in unit testing, but not just a handful. I counted 68 patterns, including things such as using literal values in your tests. It crosses a line from a few useful patterns to 900 pages of mostly basic programming practices, each described in such detail that you'd think nobody's ever heard of using literal values in their code before!

It's nice to have universal names for various programming techniques, but sometimes it feels like this can just make common techniques sound far more esoteric than they really are. For example, what would you guess "dependency injection" means? Sounds fancy, doesn't it? Like somehow one procedure hacks into another and changes its dependencies? Nope, dependency injection just means the practice of passing a dependency as a parameter.

I did get a couple of nice tips from this book. Not really anything I couldn't have figured out by myself, if I was presented with the problems the patterns were designed to solve. I do feel like I have a better grasp of all the various terminology used in unit testing. But it's certainly not worth 900 pages.

[Jo · Rating 4 out of 5]

The most exhaustive work on test automation practices & patterns I've encountered to date.

The book starts with some general outlines: "why", "how", "when",... but is mostly a smell & pattern catalog -including all the redundancy and back-referencing a pattern language implies-.

Topics covered: designing for testability, organising tests, state vs. behavior verification, setup/teardown patterns, getting untestable code under test, tests and databases, dealing with asynchronicity, ... http://xunitpatterns.com/index.html contains a summary of most topics covered in the book.



Don't read this in a single sitting. Do keep this on hand when you're having problems with a specific test and/or suite and want to build a list of options on how to improve.

[Robson Castilho · Rating 4 out of 5]

Very solid guide about coding high-quality tests.
Being a pattern catalog and a very extensive book, it's better using it as a reference guide or reading it in steps (maybe interleaving it with other books). One issue about being a big pattern catalog is the repetition of samples (and even text) from one pattern to another.
But the major disappointment is not mentioning anything about using Builders for creating Test Data and even Test SUTs (I strongly advice reading about that).

[Stijn · Rating 4 out of 5]

Amazing book! A deep dive into the world of Unit Tests and the Refactoring of Test Code. So many valuable principles and patterns that you can use in your daily practice.
Every individual who calls themselves a 'Professional Developer' MUST read this book.

[Rod Hilton · Rating 5 out of 5]

I know a lot about unit testing. I'm a big TDD advocate, and I've learned an awful lot of lessons about effective unit testing over the years. I could easily give a series of talks on the topic of unit testing.

And yet, I don't think there's a single thing I know about unit testing that isn't covered in xUnit Test Patterns. This book is the bible of unit testing, unbelievably thorough. Nearly every aspect of unit testing is covered (at least that I know about), categorized into patterns and organized into a very, very good book.

The book is huge, clocking it at nearly a thousand pages. The title also isn't terribly accurate, it's really more about the Patterns than the refactoring. But those two issues aside, this book will take you from unit testing novice to unit testing ninja easily.

As with most Patterns books, if you are already well-versed in the topic, you won't learn all that much new except for consistent terminology to apply to your knowledge. I knew most of what was in the book already, and found myself reading the Narratives section and the Test Smells section, but largely skimming the details of the Patterns section itself, most of which is spelled out pretty well in Narratives anyway. Mostly, I learned a lot of new terms that will help me communicate effectively with other developers, and I picked up a bit of new material (mostly from the Test Smells section).

xUnit Test Patterns is an excellent but long (and slightly dry) book that I highly recommend for anyone who has some familiarity with unit testing, but doesn't consider him or herself a pro.

[Gishu Pillai · Rating 3 out of 5]

My primary complaint with this book - it's too big. That's a shame - since there is some good stuff in here that needs to be read.

I've seen first hand that 'bad xUnit tests can be worse than having no xUnit tests' - teams sink hours trying to keep their tests green, while the tests are like christmas lights flickering red n green on their own accord.

Tests are code - the same rigor n quality procedures need to be applied for tests. If not the tests can cripple and impede development (instead of being an 'enabler')

[Vasili Puchko · Rating 5 out of 5]

It's the Unit Testing Bible. It's highly informative, it covers almost everything a developer should know about Unit Testing. It's big, but it's a very good time investment if you want to become a great programmer.

[Rob · Rating 5 out of 5]

This is a huge, comprehensive book, containing every testing pattern I knew of and many more.

The first ~200 pages build up a convincing narrative of philosophies and practices around automated testing strategy, touching on important patterns as they come up.

The remaining ~600 pages explain each smell and pattern in detail. This pattern catalogue shouldn't be read front to back. I skimmed it, and paid more attention to interesting or important patterns. I'm sure I will refer back to it in the future.

The most interesting set of patterns for me are the ones related to test doubles. The author's categorisation of different types of test double (stubs, spies, mocks and fakes) clears up a lot of the arguments seen online about the subject, and helped me to understand the different reasons we replace dependencies during tests. For example, mocking is useful if you need to verify indirect outputs (if they would otherwise be untested), and stubbing is useful if I need to provide specific indirect inputs (e.g. to inject an exception or another output that's hard to generate from the real dependency).

The strength of this book is that it doesn't present just a single view of testing, but many. The author treats each point of view fairly and respectfully, explaining the rationale behind every pattern, where it can be useful, and what are its drawbacks.

The only thing I think was missing from this book was: what should the system under test be? One class, one module? Should you test non-public classes and methods? Should you test only through the ports of the ports and adapters pattern? It's mentioned that it's best to test through the "front door", i.e. the public API, and that system-level tests can test through the UI or, ideally, directly on the service layer, and in most of the examples it's implied that we're only testing one class or a small group of related classes. It would have been interesting to read some discussion specifically about test granularity.

[Fabian · Rating 4 out of 5]

It is a reference book and a good one at this.

When I started reading the intimidating number of pages I soon realized that they reduce fast, since I skipped the redundant parts. But redundancy is very important for a reference book and will help me a lot when I need to find information when I need it. And this is the second aspect it is very good at: Structure. It is very well structured with different approaches to the topic and a comprehensive index and appendix.

The only caveat I see is, that it could use a new, updated edition. Some of the new framework that have evolved are not included. The xUnit Framework itself is not mentioned, AutoFixture and all the modern Mock frameworks are missing.

[Ellie · Rating 3 out of 5]

I have no compunction about claiming reading credit for having read ~580 pages before throwing in the towel. As others have noted, this book is ~200 pages of great content inside an *800* page package. In addition, large swathes of it have been rendered largely irrelevant due to 1) the sophisticated features of modern programming languages and test frameworks like Jest/Rspec and 2) industry convergence on best practices. There are some good ideas here - the emphasis on the value of testing for speed/quality/documentation and the breakdown of mocks/spies/stubs/doubles in particular - and I’m sure it was ground-breaking for its time, but there is *so* much more content than there needed to be. I’ll save my 800 pagers for Brandon Sanderson!

[Georgi Kolarov · Rating 5 out of 5]

Изчерпателна книга, може би дори малко прекалено. Препратките из целия текст на очевидни неща са малко досадни, а някои неочевидни нямат такива.
За мен беше много полезно, че примерите са на java и лесно се превеждат на C++. Поради това имаше и недостатък, конструкцията finally я няма в C++. Въпреки това беше полезно, понеже насочва читателя да осмисли проблема с унищожаване на "останките" при краш или exception.

[Samuel Taggart · Rating 4 out of 5]

A bit long and repetitive but very good content. If you are looking to learn about unit testing, there are probably better, more approachable books. However if you need to manage a large amount of tests, then this book is a gem. It is 900 pages so I don't recommend reading straight through as I did, but it would be great for a reference.

[Jakub Zalas · Rating 5 out of 5]

A comprehensive resource of patterns for writing tests. Presents patterns in a neutral view, showing an appropriate application context for each.

There would be a lot of less confusion in software development community related to writing tests and involved terminology if everyone read this book.

[Umang Bhatt · Rating 4 out of 5]

Natural successive read after Kent beck's book.

[Álvaro Hernández · Rating 5 out of 5]

Must read! for anyone who is writing software, therefore should be writing tests

[Matt McCormick · Rating 2 out of 5]

Very tough to read through as it's laid out as more of a reference book with many references back and forth to other sections.

[Kiril Kirilov · Rating 5 out of 5]

The. Best. Book. About. Writing. Tests. For. Developers.

[Arran Bartish · Rating 5 out of 5]

Assert awesome

Excellent book. When your code sense already tells you what makes a good test or a bad one, xUnit Test Patterns can explain why.

[Yaroslav · Rating 4 out of 5]

Dull yet comprehensive xUnit patterns overview

[Uli Kunkel · Rating 5 out of 5]

Some very good take-aways to keep in mind whilst your WRITING your code.

[Luís Soares · Rating 3 out of 5]

Worth it as a reference in terms of testing patterns and standardization of testing terminology. I'd give a 5 if it was rewritten in 300 pages and not so repetitive.

[Edward · Rating 4 out of 5]

A huge tome on everything xUnit. Part 1, the Narratives, explains all the basics and I would recommend reading completely. It gives a great overview of both the test "smells" and the patterns in later sections. Part 2, the Test Smells I think of as Martin Fowler's Refactoring book, except dealing strictly with testing. It's organized very similarly to that classic book. Part 3, the Patterns, is like Fowler's Patterns of Enterprise Application Architecture, except again, only dealing with common patterns in designing software tests. This last section I have not yet read entirely, but use more as a reference.

A note on the Kindle edition. They did this right. A link for every pattern, smell and glossary term. Very easy to bounce back and forth, which is essential in a reference work like this. This is especially true with the Narratives where some pages contain a dozen or more links to other sections of the book. Very well done.

[Damon · Rating 3 out of 5]

I thought this was a good book, particularly if you're new or somewhat new to automated testing. I was a bit disappointed personally though as I found that what other reviewers have said to be true: the book is about 3x longer than it needs to be.

The book is fairly repetitious. You'll find a chapter discussing a subject. Then there will be a section describing that subject as a pattern. Then each of the variations of that pattern (which were already discussed) are discussed again as separate patterns.

And the patterns are good from a high-level but I was looking for perhaps one more level of detail with more tactical examples. I understand that you can setup test fixtures by re-using data or creating all new data (which may be destroyed at the end of the test or new data is guaranteed to be unique). But I was hoping for more detailed examples about how to setup and organize that kind of data. How do you setup complex fixtures?

[Väinö Leppänen · Rating 3 out of 5]

This book is not meant to be read in its entirety, so I did not. The first 181 pages that I did read gave a nice coverage of unit testing with (surprise surprise) a particular focus on xUnit tools. The book moves along in a logical fashion, each chapter building on the previous ones which I consider to be very important. The contained illustrations I didn't care for too much; mostly I thought they were unnecessary for me personally but I can see that others might benefit more from them.
After the first 181 pages the catalog of smells and patterns begins. This in fact covers most of the book, which is over 700 pages without the appendices. As time goes by and different testing needs emerge, this catalog is a good thing have handy.

[Helge Stenström · Rating 4 out of 5]

Good, but it repeats itself a bit too much.

[Stefan Teixeira · Rating 4 out of 5]

This book is definitely the "Unit Testing Bible". It's a great reference book and it covers everything you could imagine about unit tests, which is very valuable. Despite its focus on unit testing, much of the smells, patterns and techniques covered by the book are definitely applicable to automated tests in other levels, such as integration or UI.

However, the book is VERY repetitive. If you want to read it in its entirety, be prepared to read the same things all over again for multiple times. I recommend to focus on Part I and in Part II/III just focus on the topics that you want to review.

[Johnny · Rating 5 out of 5]

A great reference book on patterns around testing, not so interesting to read from cover-to-cover. However, when you have a problem with your automated tests, then there is most likely a solution in this book.

Many problems you run into with starting test automation are covered. I wish I had read this book years before and would not have needed to make the errors for myself. If you are testing your software with automated tests, then this book is a must-read. Don’t shy away because it has so many pages. Go on and read part one and the chapters who answer the questions you have at the moment. This will be time well spend and saves you hours of pain.