The Art of Unit Testing

There are some categories of knowledge that a professional developer learns in the course of their work, without making any special additional efforts. For example, few of us have read a great book on regular expressions by Jeffrey Firddl to get acquainted with the topic of the same name. Of course, there are a lot of people for whom “regwires” have become the meaning of life and cannot do without such fundamental knowledge. But in most cases, a pair of small articles and information in the relevant section of the documentation will be enough for more or less comfortable work with regular expressions (if such a thing as “comfortable work” with regular expressions exists at all J).

Similarly, we usually refer to the study of unit testing. After all, unit tests are not rocket science; to study them does not require many years of preparation and a lot of sleepless nights spent on studying the thick Talmuds from the unit testing gurus. The concept of automated code testing can be explained in 10 minutes, and by becoming acquainted with one of the xUnit test frameworks (another 15 minutes), you can work with any other framework almost immediately. Then it will be necessary to spend another 20 minutes to study some insulating framework, such as Rhino Mocks, and, voila, we have another professional in the field of unit tests.
')

Such a level of proficiency in the tool, backed up by experience, pragmatism and common sense, is sufficient for comfortable work, so you might get the impression that an experienced developer will not benefit from this book. I, frankly, had the same opinion and would hardly be interested in this book if I did not have to prepare a unit testing report for our American colleagues. After all, one thing is to own a question for your own use, another thing is to introduce something new and change the outlook of the development team, most of which are your bosses.

Looking ahead, it’s worth saying that I’ve been mistaken with the The Art of Unit Testing by Roy Osherove book will be useful even for experienced developers, but let's get everything in order.

The structure of the book is such that the author goes from the most simple and basic concepts to more advanced things. It starts with simple examples and definitions, gives an introduction to TDD, talks about the “seams” of the application and the use of “fakes” such as moki and stubs , and also briefly describes various insulating frameworks.

From the very beginning, Roy is trying to hammer one important thought into the reader's head: quality tests are no less important than quality production code! The whole chapter 7 of The pillars of good tests is devoted to what are good tests, but even outside it, the shadow of “good” tests will haunt the reader almost constantly. Probably dozens of books and countless articles have been written about the quality of the code; we all know how important it is to write easy-to-maintain code and what to do to improve its quality. But our attitude to the quality of tests is often not so meaningful, although bad tests can ruin your life just as well as $ o-code in business logic.

There is no point in writing bad unit tests, unless you are new to this business and do not learn how to write good tests. If you are inadvertently going to write bad tests, then with the same success you can refuse from this activity altogether. This will save you from the troubles associated with delaying the schedule and save you from additional problems with maintenance.

It's great that, in addition to the principles of unit testing, Roy pays attention to such important aspects as the introduction of unit testing in organizations, the testing of legacy code and the impact of tests on the design of the application. In terms of design, Roy believes that testable design is primarily due to the limitations of the language or programming environment and does not exist in dynamic programming languages (since we can “lock” everything we can there). I disagree with this approach, because I believe that good design by default is good for testing, and that the ability to write unit tests is a good sign of the simplicity of class contracts and a sign that the class does not take on too much.

NOTE
More information about the use of unit tests as a “litmus test” of a bad design can be found in the article “Ideal architecture” .

As Roy himself admitted, he spent 3 years writing a book - and this is more than he spent on the “creation” of his two children, and it is felt periodically. For example, in different places of the book, different format of class diagrams is used, sometimes the name of test classes and methods is different, and in general, the feeling of déjà vu visits periodically. There are other minor notes. Thus, the author for two hundred pages uses the standard syntax of statements of the NUnit library, and from the 200th page, suddenly begins to use Assert.That and declares that this syntax is more declarative. Obviously, a year and a half after starting work on the book, Roy got to this syntax, which he liked, and there was no more time and effort to change the previous examples.

The only significant note to this book is the weak disclosure of the topic of parameterized unit tests. Yes, Roy mentions in passing about this possibility, but very superficially and somewhere near the end of the book. There is some unfairness when the author spends 4 (!) Pages on how bad it is to count on the order of launching a unit of tests, and 2 paragraphs are spent on parameterized tests that can save a lot of time and significantly increase readability of tests.

You can find other moments in which your opinion will differ from that of the author, but in general, the book “The Art of Unit Testing” is one of the best sources of information on the subject of unit testing, which can either change your outlook in the right direction, or generalize and structure already existing knowledge.

Rating: 4+

The Art of Unit Testing

Related links

Books

Podcasts

More articles: