Book The Art of Unit Testing with Examples in .NET

The first time I got close enough to testing 5-6 years ago, just the beginning of my career. Then, I remember, I was told about covering the code with tests. Moreover, I was not asked to write any Unit tests, they simply said: “you see if with three conditions that you wrote, you should check all these three conditions”. The implication was that I, after writing the code, had to analyze it, and fully test it with a regular walk through the application interface. How do you? Over time, the knowledge in testing has grown a little, I learned a little how to write tests. I still have not seen or participated in any living project written using the Test Driven Development (TDD) approach. The basis of my knowledge was in spying on how my colleagues in my previous office were doing, reading articles (for example, Alessandr Bindhu had an excellent article “ TDD for beginners. Answers to popular questions ”), watching a couple of crunchbacks. I decided to put an end to illiteracy and get into the subject; for this, I sat down to read the book The Art of Unit Testing with Examples in .NET . Moreover, in the current office? it can be said that only I write tests for my code. Need to be a model.

This book was written about a year and a half ago. I chose it not by chance, even php programmers recommend it , although most of the examples are written in C #. And since I saw quite different recommendations for reading this particular book, I decided to start with it in order to end illiteracy.

The author of this book, Roy Osherove, is a fairly well-known blogger , he also conducts TDD workshops, sometimes he works as a consultant for offices that want to apply TDD in their projects (and he writes about this many times in this book, citing successful and not successful examples of implementation of the methodology). He works as chief architect at Typemock , which produces paid tools for more convenient test writing and code analysis.
')
The book, in principle, will be useful to developers of any platforms and languages. In the examples, C # is used as the experimental language (there is some Java code), NUnit as a framework for writing Unit tests, and Rhino Mocks framework for using Mock and Stub objects in Unit tests (by the way, I did not know that these were different things , knew only Mock objects). For other platforms and languages, it will probably be possible to use only the theory, which is abound in the book. Or if there are similar frameworks for your platform, then you will be able to familiarize yourself with them and translate the code of the examples into them. At least, I am familiar only with the Moq framework, but to understand the syntax of Rhino Mocks for me was not difficult.

So, what is the book itself about? As always, there is an opportunity to download a couple of chapters on the official website of the book in order to start getting acquainted with the book: in order to evaluate whether it suits you or not. As far as I know, it has not been translated into Russian, and since the time has passed enough since it was released, it most likely will not be translated. The book begins, like any other with the chapters “Hello world!”, About what it takes to write tests, what tools, and the first test is written. Further, the frameworks that the author will use in the examples are quite briefly described: NUnit and Rhino Mocks. The author made an emphasis on Rhino Mocks, as far as I understood it, because in his blog he once collected statistics that this framework is used more than others. It seems to me that the situation has now changed, and the more popular framework now is Moq . Well, NUnit remains the same popular framework for testing. At one time, I switched to MbUnit, because there were more opportunities, but NUnit is currently well-pulled and caught up with a competitor.

The farther, the book becomes more and more interesting. The principles of writing tests are described in sufficient detail, how they should be designed, and the main thing is that antipatterns are given, which I immediately recognized in my code (I need to improve, now I know where).

I also received an answer to my old question. I once wrote an article Testing NHibernate applications using MbUnit as an example , and then I received one of the comments :

I have a question. What for? Why test ORM? Sobso the whole piece of interaction with ORM is placed in a separate class (separate classes), and some IoC container is used.
What exactly are you testing in ORM? Mappings? Requests?

There I had a little specific case, because I got out beautifully, that, it seems, was necessary. Although I did not understand, why not: this is my integration test, I check that the structure of the database corresponds to the mapping, the mapping corresponds to the classes, if I use special requests, I also test them. Not once saved. In general, I did not know what to answer. In the book, I received an answer to my question - this is useful and necessary, the author also tests the data access layer, and gives arguments for why.

In addition to how to write tests correctly, the book will find information on how to implement TDD practice in your office, how to make writing tests more efficiently, how to work with Legacy code (and this is very important when entering TDD for an existing project) . And the main thing is the answers to the most common questions that need to be answered when you become the person who decided to introduce TDD in a team (questions related to time, money, knowledge and the rest). I tried to somehow explain this to my new colleagues, they left me, but the arguments were not strong.

Also in the book there is a review of a large number of frameworks that can be useful for testing. Among which, of course, there are paid frameworks written by Typemock , where the author works.

I recommend the book to all offices that practice TDD in themselves, and who simply write tests to their code (this is my case), but in general to all offices. And my recommendation to the leaders and managers, do not say “Write tests”, but read the book yourself, or ask the staff, then conduct trainings, and everything will change. I think this is a very important part of the development. I have already written many tests, but after reading the book I realized that they could have been written much more correctly and more clearly. The book contains excellent recommendations. I can not say that it contains all the answers, and I can not say that I agree with the book in detail, but that the book was worth reading is for sure.