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.
Scott Ambler’s Agile Modeling site is focusing on effective practices for modeling and documentation. Contains tons of useful information and resources including for example “Where do I start?” materials, and various essays: Agile/Lean Documentation: Strategies for Agile Software Development, or Introduction to Test Driven Design (TDD) to name a few. In addition, there is a page related to all his books, e.g. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process.
My company is using TargetProces as a project management tool supporting Scrum – we have two georgaphical locations and have to use some software to coordinate Scrum. The tool is really nice, and I should say that it is missing only few functions that I would like it to have.
Today I got an email from Share-it! (Share-it! is handling ordering for TargetProcess) saying that my TargetProcess subscription has been cancelled “due to an unsuccessful automatic payment which was due on 31-JUL-2008″. Reason: my credit card info in their database had old expiration date and somehow I did not update information to reflect my new card. Shit. When I went to “Buy” page, there was no option to “update” expired subscription – only to get a new one (meaning I would have to pay 5 times more).
But guess what… I contacted TargetProcess “Live Chat” support, and my problem was solved within 2 (yes, TWO!) minutes – they IMMEDIATELY provided my with another order page where I had to pay only for subscription renewal and now, 5 minutes after my struggling started, it is completely paid and delivered. Wow!!! That is cool! Thumbs up!
By the way, this was not the first time I have turned to their support, both technical and sales, and, to my pleasure, I ALWAYS got IMMEDIATE resolutions to my issues. TargetProcess people do a really great job!
So, why all this rant? I just wanted to share at least one good experience in today’s world of “outsourced support”. I would say that this was perhaps my “smoothest” experience with any support people so far – no blaming, no pushing responsibilities – they just did their job.
Just returned from the two day Certified ScrumMaster Training held in Helsinki by Dan Rawsthorne from Danube. It was great! Very informative, makes you think, you learn in two days more than in a few months. Definitely can recommend! Have tried doing Scrum on a “real” project (making a brochure :), and guess what? IT WORKED! Cool! :)
Excellent video-presentation held by Ken Schwaber at Google.