I read Eli’s posts Firing Events Made Easy and How To Isolate Future Instances last week and it hit me that this was ground breaking. The capability that he demonstrates in these posts open doors that were previously shut without refactoring. That is to say that your tightly coupled winform can now be programmatically tested with in frameworks like Fit and xUnit. This has got to be the sharpest mocking tool available for .NET.
You maybe a little confused at this point. My pals at work were when I excitedly explained this break through to them. They thought that I did not like TypeMock.NET. I clarified for them that TypeMock is an extremely sharp tool. I like what Jeremy D. Miller says about sharp tools in his Programming Manifesto:
My point being that just like a sharp knife or power tools, “sharp tool” techniques are safe when combined with some proper precautions (TDD). Of course I’ve got a little scar on my bicep from shooting myself with a pneumatic nail gun, so what do I know about safety?
I think that I am also inline with Ron Jeffries view:
I’m told that in the olden days, when one was working to become a
machinist, the first project you were given a chunk of metal and a
file and told to make two pieces, one with a square hole in it, the
other with a square peg coming out of it, that fit perfectly
together. Later, you got to play with the machines.
I explained to my buddies that it is not the wisest thing to do: hand out sharp tools and not educate people on how to use them.
Getting a laceration aside the only real argument that I could see against it is: The effort one would put into controlling TypeMock could be better spent on refactoring the test subject into a more naturally testable subject. A code generator to produce the blocks of code to control TypeMock integrated into the IDE you could easily defeat this concern. I talked to Eli about this and he said “We have plans to create a GUI pack and a Recorder pack…”.
It seems to me that tool side of things are shaping up very well. Take MbUnit, FitNesse, TypeMock.NET, ReSharper and CodeRush. This toolset will let you do some amazing things if you take the time to learn. It is nice not to need so much courage.
Primal Leadership: Realizing the Power of Emotional Intelligence (Unabridged)
Daniel Goleman, Richard Boyatzis and Annie McKee
I am still reading this one. I find the discussions on what parts for the brain do what very interesting.
This reminded me an awful lot of Agile.
Integrity: The Courage to Meet the Demands of Reality
Henry Cloud
I liked this book very much. Pair this with The 7 Habits of Highly Effective People and you have two of the best books on personal growth. Kent Beck suggested this one to me. Thanks again Kent. 
I would read Integrity first. This is a short book on how and why to generate trust.
Leadership and Self-Deception: Getting Out of the Box (Unabridged)
The Arbinger Institute
This was a very fun read. I have never hear a bok like this before. It was more like a story. The book is about how we deceive ourselves. They call it being in the box. You are in the box in relation to another person. When you are in the box you don’t treat people like people you treat them like objects. Most people spend most of their lives in the box.
One of the examples I connected well with was: A manager had been using a white board in a conference room to store ideas on. He had communicated to everyone that they needed to ask him before using the room and or the white board. Someone used the room and erased the board without asking. He told them how wrong that was but did it in a way that showed contempt for the wrong doer. He was in the box. This damaged their relationship and their ability to produce results for the company. If he had threated the wrong doer as a person while holding them accountable the outcome would have been far more productive.
They explain how one gets into the box and stays in it. They also explain how to get out and stay out of the box too.
Lincoln on Leadership: Executive Strategies for Tough Times (Unabridged)
Donald T. Phillips
I want to work for the modern Lincoln.
I was reviewing a yet to be published article by Stefan Jungmayr, author of Improving testability of object-oriented systems. I got his permission to share a quote from it that struck me as the most profound difference between good OOD and Testability.
Indirect dependencies are much more relevant to testing than to implementation tasks because their potentially negative effects on test tasks are not reduced by design techniques like encapsulation and information hiding.
Many times testability is the only force in the system that puts focus on indirect dependencies. When I was prototyping DX Testability I diverged from the standard way for computing Efferent Coupling. I counted indirect dependencies as well as direct. I knew that indirect dependencies are important to testability yet I had not put together how in most cases they are not a concern in good OOD.
A simple example of this that most can relate to would be if our test subject or one if its dependencies had an indirect dependency on the application’s database. If you are working to place your test subject under a unit test you will be forced to deal with this indirect dependency.
Point being that testability deserves direct attention. It is not something that is just of interest academically. If you value unit testing then testability is of interest to you.
