The art of unit testing with examples in .net
Essential C# Developer Reference book
If there is one book I would advise every C# developer to own, it would have to be the art of unit testing. In fact, I would go as far to say that almost every developer should at least read the book. Especially if they're currently writing unit tests, or even thinking of starting to write unit tests.
Why I read this book
Unit testing is one of those things, that developers will naievely tell you that they completely understand it and that they know how to do it. I know this, because I was one of those developers!
I'd read a couple of articles and blog posts on Unit Testing and TDD, done a couple of exercises and even implemented a few nUNit projects and I really thought I knew what I was doing. Then one day, I'd read a blog post by Aynde Rahien about Rhino Mocks, and I suddenly found myself not really understanding what he was on about. Fortunately, the blog post also contained a link to an article by Roy Osherove and I was able to clearly understand his explanation. I enjoyed his article and noticed that at the time he was promoting this book!
What I learned this book
The book is a perfect guide into learning and understanding the topic, irrespective if you're a C# developer or not. The code samples may be in C#, but the reality is the concepts and implementation are the same in any language.
After reading this book, I have been able to write comprehensive units tests in PHP, JavaScript, Python and have even started learning in Go. The true value, is learning and understanding the art of unit testing.
I have read reviews and spoken to many developers who claim to have read this book, and they often use the line that it validated what they were already doing or knew. However, when you read their code or more directly their Unit tests they're still doing it wrong!
I think I was in some cases probably still am one of those developers who thought they already knew everything they needed to know about unit testings. Once you've learned about Dependency Injection, some patterns and practices and being able to Mock and stub classes and objects what more is there to know and learn, right?
Wrong! they all are certainly factors that help in writing unit tests, but they don't necessarily help in writing Good Unit Tests.
There certainly is a huge difference in code with unit tests and good code with unit tests. This is one of the many observations I gleaned from this book, by realising that a lot of the unit tests I had been writing were for the most part pointless.
Yes, I was getting the Code Coverage, to satisfy all those statistical analysis tools for Unit Test coverage, but the reality was the unit tests were not really adding value. In most cases, unit tests were just another checkbox tick on my daily to do list. I really wasn't that interested in writing them.
All that changed after reading this book. Dare I say it I actually started to enjoy writing unit tests and because of learning and appreciating their value, the quality of my code improved.
What I liked about this book
There are a number of points this book raises that should ring bells for all developers. Personally, I found the list of qualities that good unit tests have and also the problems that keep us from having good unit tests. The book then defines practical techniques for correcting those problems.
I'm not the biggest fan of pure Test Driven Development (TDD), there is just something about it, that for me seems to curb my creativity. So it was a relief to learn that although Osherove recommends TDD he doesn't necessarily proscribe it, saying that having good unit tests is more important than a process.
, and once you understand testing techniques you can start to explore those other processes.
I still don't implement pure TDD, but I still take time have good unit tests. I do find myself, at times thinking in pure TDD and I do try implement it, but I still find myself reverting back to my traditional approach. So I guess my style and process of developing is a hybrid.
What I did not like about book
Some developers may be put off from buying this book, based on the fact the Second Edition of this book was published 2013. However, I must say, don't let that deter you.
The content, strategies and practices contained in this book are not bounded by time or technology, and there are many things you can learn.
The book itself may be predominantly focused on nUnit, but Osherove takes the time to discuss the testing frameworks and isolation frameworks that he has found useful in his own work. Which will provide you with background and in insight to investigate and select tools for yourself.
Personally, I now prefer xUnit, but I did and have used nUnit, msTest for long periods of time. I just found that xUnit has everything I need at this stage. I'm sure it's probably not the best framework around, but it's good enough for my needs.
What I learned from this book
Osherove also provides some signs that you may have an over-complicated test or a test that tries to test more than one thing. For example, if you have control statements (switch, if, else) or loops (foreach, for, while), then you probably have logic that should not be in a test.
Along with this are a set of "smells" that you may have a problem with your tests. This includes things like constrained test order. If your tests have to be run in a particular order, then you have a dependency or shared state between tests that needs to be corrected.
I really appreciate a practical view of code coverage. Code coverage is not a silver bullet!
You could easily have close to 100% code coverage with bad tests that don’t mean anything. Low coverage is a bad sign; high coverage is a possible sign that things are better.
I have worked on teams that have cared only about ensuring they have 100% code coverage and teams that couldn't care less about unit tests. The reality is one couldn't differentiate between the levels of shitness of both code bases.
One should never assume that just because code is unit tested, that it is quality code! True quality code is written by developers who care about the quality of the product they deliver. Unit tests will be a feature of their code, it may not necessarily be the feature of their code.
Why I recommend this book
I believe this book, should be one of those that is on every developers bookshelf. It's been invaluable to me, and I often find myself refering back to it time and time again.
- What is this Directory.Packages.props file all about? - January 25, 2024
- How to add Tailwind CSS to Blazor website - November 20, 2023
- How to deploy a Blazor site to Netlify - November 17, 2023