VS11 Fakes Framework

It seems to me that Microsoft still doesn't quite understand the serious TDD culture.  I recently saw an InfoQ article entitled VS11 Gets Better Unit Testing Tools, Fakes Framework.  My assumption is that the word "better" in that title applies only to the unit testing tools, not the fakes framework.

Although, I like that Microsoft has, for a while now, recognized the existence of the testing community and that they are trying to improve their tools to fit that need, it seems that they often miss important details.  Admittedly,  this is beta, and I only know as much about their fakes framework as I've read in that article and links from that article, however, it seems from what I read that they are not including mocks in their fakes framework.  They have stubs, and what they are calling "shims".  Shims essentially allow you to provide delegates to operate in place of the actual method calls on the object you are faking, so kinda like stubs but more like a fake since you can actually provide a method that executes so you can do more stuff than just specify a return value. This would be great, except that it is completely unnecessary and I think it is going to lead to some awful, spaghetti-like test code.

The other problem I see with shims, if I am understanding how they are implemented, is that you use Visual Studio to generate your shim classes.  On a side note, I was very happy to see they are deprecating private accessors, but it seems that shims are going to have a lot of the same problems. For example, if I am coding against a shim and I decide I don't like the name of a method on the object I am shimming, I'll want to refactor it right there.  I fear that, just like private accessors, if I refactor a shim, I am only refactoring the shim, not the real class, and so shims are going to be an obstruction to refactoring, just like private accessors are.

If Microsoft wants to include a fakes framework in VS, I don't understand why they don't embrace what is already working well in the TDD community.  Fakes frameworks such as RhinoMocks and Moq already give you what you need and they both embrace the Arrange-Act-Assert approach which leads to much cleaner tests.  With Arrange-Act-Assert you setup your test at the top of your test (arrange), then make the call to the system under test (act), and then you do all your assertions.  By not including mocks, the VS11 fakes framework will cause people to have to do assertions as part of the arrange phase of their tests as suggested in the InfoQ article when the author stated, "Mocks are missing, but you can do assertions within the stub method implementations."


Perhaps the most frustrating thing about this new fakes framework is that we will have lots of people, who are earnestly trying to learn how to do TDD, and they will learn that shims are the right thing to do and they will have no understanding of a true mock.   That means that, even though I can just ignore the existence of the new fakes framework myself,  developers everywhere will start doing things the Microsoft way and someday I'll have to work on some code somewhere that uses shims instead of something more reasonable because they have embraced the new framework.


In my opinion, this is another failed Microsoft attempt to emulate what the rest of the development world has already figured out.

Code Simply

I've been coding for a quite a while.  Unfortunately, I spent a lot of my career not realizing I was writing bad code.  A few years ago, I think I started to learn what it really means to write good code (of course, I thought that at the beginning of my career too).  This happened when I began working on my first real agile project.  The methodology was XP.  I started learning about things like loose coupling, dependency injection, test-driven-development, etc...things that began to help me write more simplified code.  Having said that, I think I've always had a propensity to try write the simplest code that could possibly work; I just didn't always know how.


Of course, I've written code that started out simple and when I was done I looked back and thought it was a mess.  And, admittedly, I still do that.  It seems inevitable that today's pride will always be tomorrow's embarrassment.  But I do feel I'm doing better.


All around me I see examples of things I could do better, or at least, when I open my eyes that's what I see.  There are some things that I believe in that have become guiding principles, things like loosely coupled classes, test-driven development, preferring composition over inheritance, the simplest design that could possibly work, etc.  And there are other things that seem like a good idea and that I hope are right, things like Domain Driven Design, for example.  And of course, there are more concrete things that I recognize I could learn more about, like when Mike Clement (@mdclement) tried to melt my mind recently in his session "Linq (From the Inside)" at Utah Code Camp.


The more I learn, the more I realize how much more there is to learn. Some things, when you hear them, seem obvious and simple, others can be quite complex and difficult to understand at first. The interesting thing is, learning complex and difficult things about writing good software doesn't lead to more complex code, it leads to simpler code.  The more we learn, the more we are empowered to create clean, simple code.  The measure of a good developer is not his (or her) ability to create impressive frameworks and complex code; it is instead his ability to identify the most simple solution to a given problem that truly delivers all the desired features to the user.  I hope to be able to learn to do that better.


I've found that as I learn, I want to share, and that has led me to create this blog.  


It can be my chronicle of today's proud moments turned into tomorrow's embarrassments published to forever live in infamy on the interwebs.