Agile Ruined My Life shows an interesting perspective on the subject, and I really share author’s view on many of the points enumerated – there are too many things in today’s “agile” that make it really a joke. Despite this, I still believe there is a “right agile”, but it really has nothing to do with dumb religious following of “holy agile scriptures”; instead, agile must be pragmatic and flexible, or otherwise it turns into a cargo cult with all the negative consequences.
Finally I am back! :) Last year or so I was really busy working on our product, but now we are basically ready, and I can spare more time for “hobbies”.
Ade Miller, development manager at Microsoft patterns & practices group, blogged about launching of patterns & practices Agile Development Showcase. Among others, that resource features interesting Distributed Agile Development at Microsoft patterns & practices article.
Today was Sunday and I took a “day-off” from the project :) and decided to look into the world of mocking… Before I start, I should admit, that while I understand (or at least I hope so) principles and benefits of Test Driven Development (TDD) and mocking, I have never used them in my work. There are a few reasons for this:
- Currently I am developing a digital TV feature and infrastructure for an advanced set-top box (running on Windows XP Embedded), and simply do not get how I can use TDD and mocking with needs like processing 25-40+ megabit transport streams and doing something useful with them. The code that I would be able to test using TDD and mocking is way too simple for this, and the code I perhaps would be interested in testing automatically, is not really “testable” for the abovementioned reasons.
- Unit testing and mocking frameworks for C++ and C++/CLI, the two languages I use 80% of my time nowadays, are quite “anemic” at best, and it is really no fun to use anything like those frameworks.
- On top of that, to be honest, I never felt the need to use TDD and mocking in my own practice. Retrospectively thinking, I do not remember any project where TDD or mocking would substantially improve the quality of my code and/or reduce the number of defects (although I definitely know cases where it would not harm to use TDD and mocking) – I am not “boosting” myself, but there is an order of magnitude difference in performance among developers, and even bigger difference in quality of the code they write. In fact, I think TDD and mocks were invented to somehow compensate for this difference.
- I somehow have a weird feeling about adding to my project as much testing/mocking code as there is “normal” code. And then, I am definitely not “purist” but rather “pragmatic” – I agree that it might be wise to have unit testing/mocking in some parts of the system, but definitely not everywhere.
So, now that I explained my background, I am ready to continue. After spending quite much time on Google and other development-related sites I managed to narrow the list of available .NET mocking frameworks down to three: Typemock Isolator, Rhino Mocks, and Moq. All frameworks support .NET 3.5 (Rhino has it in version 3.5 RC).
Typemock is definitely the most powerful of these frameworks, but this property of Typemock is often mentioned in the cons section. The argument is, that while allowing mocking everything and everywhere, Typemock is not really helping developers to design loosely coupled code – for example, you do not have to “resort” to Inversion of Control (IoC) principle to use Typemock. I think Typemock is as its best when you try to introduce TDD and mocking into legacy project to get better understanding of that code and to have easier time modifying it. The framework has a free version, but to get e.g. its Natural Mocks feature (allowing to define expectations by recording them in a type-safe manner) you will have to cash out 349€ for Professional or 449€ for Enterprise editions.
Rhino Mocks is likely the most used .NET mocking framework. The framework looks quite powerful, is type-safe, supports generics, and is actively developed.
Then, there is Moq – a newcomer to the scene. Some people criticize it for being too simple. Some accuse it of not being “pure”. From what I have seen today, I should say that I liked it most (second being Rhino). It has rather elegant type-safe API built around lambda expressions. This API allows writing shorter and more concise code than Rhino does. What sets Moq apart from other mocking frameworks is that it is not using the record/playback model.
I will definitely give TDD and mocking a try on my next project. On the other hand, my C++ part of our current project is much smaller than our C#/.NET 3.5/WPF code-base, so I might introduce mocking into our current project if there will be not too big “opposition” from the development team and other project stakeholders – we are under heavy time pressure now, and adding some new concepts at this moment will probably introduce significant delays. I think that the framework of choice will be Moq, although it is just a gut-feeling at this moment.
And here is the list of interesting blogs/sites about the mocking:
- TDD : Introduction to Moq by Stephen Walther
- Moq: Linq, Lambdas and Predicates applied to Mock Objects by Scott Hanselman
- kzu Weblog by Daniel Cazzulino, the author of Moq
- Comparing Moq to Rhino Mocks by Phil Haack
- Ayende @ Rahien blog by Oren Eini, the author of Rhino
- Inversion of Control Containers and the Dependency Injection Pattern by Martin Fowler
- Mock Objects – Steve Freeman and Nat Pryce are writing a book, let’s call it “Growing Object-Oriented Software, Guided by Tests”. So far two chapters are available online.