Reviewing "Angry Tests"

Just participated as one of the reviewers for "Angry Tests" by Yegor Bugayenko. This book is a practical guide to writing better tests, and I found it to be a valuable resource for anyone involved in software testing.

As software engineers, we’re used to writing tests — but we don’t always know how to write them well. We aim to cover the most significant lines of code, often guided by intuition. This book is a practical guide to writing better tests, and I found it to be a valuable resource for anyone involved in software testing — whether you’re a developer or a tester.

You can find the book, purchase options, and more details here: Yegor’s site. This book focuses on automated software testing — what to test, and how. It walks you through best practices and explains why solid testing is essential for long-term maintainability and support.

Automated testing isn’t exclusive to software. It’s used in many industries. Take manufacturing, for example: when a car is assembled, it undergoes crash tests and other checks to ensure it meets industry standards. If it doesn’t, the product is pulled back for fixes and re-engineering.

I’m not even talking about manual testing here — which many developers tend to avoid. Instead, we often test only the “happy-path” and quickly report that our feature branch is ready for someone else to QA.

Let me quote myself from my review of the draft version of the book:

As developers, we tend to do "soft testing" — testing only the happy or green path — or being too polite with our code. We treat it like our child and want to be nice to it. This is wrong. I’d even say it’s a completely flawed way of thinking. And of course, we’re often too lazy to dive deep — we’ve got deadlines, and no one really appreciates the extra two hours spent tracking down an edge case that might only occur in 1% of real-world use. But I believe we should push for better. As developers, we should go beyond just “working software.” We should actively try to break our code — with no guilt about doing so. Our software shouldn't be fragile. That wasn’t the mindset of our engineering ancestors who built systems that are still functioning today — like those used in space missions or military tech. They didn’t half-test their products with a “soft testing” mentality. At the very least, we should remember that and be honest with ourselves.

Evgeny Zhdanov

One of the reviewers

From personal experience, I can say that many times I’ve written code I thought was production-ready — only to discover bugs or poor design decisions when I started writing tests for it. Testing reveals flaws and forces you to improve your architecture.

Software testing is a topic worth hours of discussion. In fact, the IT industry now has entire roles dedicated to it: Manual QA, Automation QA. That alone tells you how important it is. Great products aren’t just made by brilliant engineers — they’re made through hours of focused work from skilled testers who approach the system from entirely different angles. Catching issues early is far cheaper than fixing them post-release — not to mention the bad reputation that can follow a poorly-tested product.

Now, let the author explain what drove him to write this book:

I wrote this book in just a few months because I couldn't keep all this information bottled up any longer. I'm frustrated with the consistently poor quality of tests my colleagues and I often write. This book is my attempt to lay out best practices in a clear, formal way — something we can all refer to and rely on. I expect to use it myself as a practical, no-nonsense reference guide, where the key principles are spelled out and easy to find.

Yegor Bugayenko

"Angry Tests" author

As the author says, it’s his attempt to lay out best practices clearly and formally. I strongly encourage you to read it — you’ll gain knowledge that will pay off later, especially when your product hits problems in production. Treat your automated tests as an investment in your future.

Personally, I really enjoyed the experience of reviewing this book. It was my first time doing something like this, and I’d encourage you to volunteer for similar projects. It’s a great way to deepen your understanding of a topic, challenge your assumptions, and find new sources to expand your knowledge.

I also have to admit — it felt great to be part of something bigger than just myself.

When I received my printed copy, I went through it page by page, checking whether the review notes I originally sent to the author were taken into account. And when I saw some of my feedback incorporated, I felt proud. We’re all human — we thrive on community, contribution, and the recognition of our peers. That’s just in our nature.

It took me more time than I initially expected to finish the review, but it was fun and rewarding. As I said, I really recommend taking on activities like this from time to time — giving feedback to others, especially on topics you care about. It’s a small act, but the return is big: your own growth and inspiration.

And of course — read good books. They challenge your thinking, give your brain new ideas, and help you become a better professional.