After buying and reading the book Dependency Injection in .NET (Mark Seemann), I was about to buy The Art of Unit Testing (Roy Osherove), when I learned that the second edition will be available in a couple of months. I contacted Roy and Manning Publications Co were kind enough of providing me a complimentary copy of the Early Access Edition of The Art of Unit Testing, Second Edition, which I have read avidly in the last few days.

I was interested in the book because while I had worked with automated testing for the version 7.0 of my MZ-Tools add-in, I was not sure if I was doing it properly and I wanted to learn about integration testing / unit testing, the difference between fakes, mocks and stubs and the best practices. After reading the book, there is no doubt that Roy knows the stuff, and explains everything to make it clear:

– Part 1 explains the basics of unit testing and a first unit test.

– Part 2 explains the three kinds of testing: result testing, state testing and interaction testing, and how stubs are used for result / state testing and mocks are used for interaction testing. The last chapter of this part (and the first chapter of the next part) explains isolation (mocking) frameworks (as well as appendix B). It seems that not all isolation frameworks are created equal (constrained vs unconstrained) and the book explains quite well how they differ.

– Part 3 has one chapter to dig deeper into isolation frameworks and two chapters that I was very interested in: test hierarchies/organization and the pillars of good unit tests. The book puts an enormous effort in the importance of writing tests that are 1) Trustworthy 2) Maintainable and 3) Readable, and I couldn’t agree more because I have written tests that don’t follow those principles… this part of the book provides tons of good practices to the point of almost reaching perfectionism.

– Part 4 has two chapters: one devoted to integrating unit testing into the organization and other to working with legacy code (lacking unit testing). It is sad that books have to have such chapters because many developers and managers don’t see the value of automated testing, thinking only about the short term costs and not about the QA in the long term. But since this is the reality, this part can help you a lot in that case.

I have enjoyed the book a lot. It seems that as part of his consulting job, Roy has seen tons of bad
practices (as any team leader has seen with any kind of code, sadly) and this edition is a new attempt to explain developers how to become artists of unit testing. If they fail, it won’t be because of this excellent book.

After hearing about Microsoft Unity from the .NET architects at my current company (my daily job), I bought the book Dependency Injection in .NET, by Mark Seemann some weeks ago to learn dependency injection and Inversion of Control (IoC) containers, just for curiosity because I thought it wouldn’t apply to my MZ-Tools add-in, or to Visual Studio extensions. I couldn’t be more wrong. I think this is the book that more profoundly has changed my mindset about creating software , because the concepts of programming against interfaces and loose coupling (explained in part 1 of the book) are one of the most important things that you need to master as a developer to create maintainable software, as now I have realized. Dependency Injection (DI) is the means to achieve loose coupling. The second part of the book explains DI patterns, anti-patterns and refactorings. The third part explains the three dimensions of DI: object composition, object lifetime and interception. The fourth part explains several DI containers of the many ones available for .NET. As the book explains, DI containers are optional, but even if you don’t use them, the software will benefit a lot from a loose coupled design.

How does this relate to developing Visual Studio add-ins? After reading the book I have realized that in my case in at least three aspects, and I wish I had read the book before:

1) Visual Studio add-ins hold a tight coupling with some dependencies such as the EnvDTE.dll, EnvDTE80.dll and VSLangProj.dll assemblies, that provide the automation model for add-ins. In all likelihood, all the features of your add-in depend on EnvDTE.Solution, EnvDTE.Project, EnvDTE.EditPoint, etc. Imagine now that you have to migrate your add-in to a Visual Studio package (SDK), because Microsoft plans to remove add-ins. It would be much easier if the features of your add-in would depend only on interfaces such as ISolution, IProject, IEditPoint that are implemented by classes that encapsulate the automation model for add-ins (EnvDTE.Solution, EnvDTE.Project), and later by classes that encapsulate the SDK services of packages (IVsSolution, IVsProject).

2) A loose coupled design and dependency injection allows to use unit testing more easily. Automated testing for add-ins is hard. So far I had done integration testing (with my own test runner), which while it is automated, it is slow and can’t be integrated easily with continuous integration (CI). Now I want to use unit testing too (because of the fast speed) through stubs, but since I haven’t used dependency injection I am finding problems to achieve a clean approach.

3) MZ-Tools 8.0 will support Visual Studio, VB6 and VBA as hosts. I am encapsulating the very different automation models with concrete classes such as SolutionEx, ProjectEx, etc. using partial classes and conditional compilation. But after reading the book I have realized that it would be better to use either interfaces or abstract classes.

I will try to find time to write a series of posts with code about using loose coupled design and dependency injection developing add-ins for Microsoft IDEs. Stay tuned.