ISerializable - Roy Osherove's Blog

I was just about to blog some myself on what principles one should follow to make code testable. The most important one I can think of is Inversion of Dependancy.

But when that has not been followed and there are no abstractions allowing for static mocks or the test subject creates its dependancies directly baring dynamic mocks things get tricky. I have been waiting for a dynamic AOP framework to help. It just so happens that Spring.NET 1.0 just came out and it includes AOP support.

http://www.springframework.net/doc/reference/html/aop.html

"Around advice: Advice that surrounds a joinpoint such as a method invocation. This is the most powerful kind of advice. Around advice will perform custom behaviour before and after the method invocation. They are responsible for choosing whether to proceed to the joinpoint or to shortcut executing by returning their own return value or throwing an exception."

I believe this kind of technology will go a long way to making traditionally untestable code testable. One should be able to isolate an object/memeber to test its responsibilities with out the rest of the system having to be brought into the mix.

This in no way should become an excuse to write crappy code (I.E. I know how to refactor so I can write crappy code and refactor it latter).

See also:

http://ivan.truemesh.com/archives/2004_08.html

Jim

Doing a “Extract & Override” means that at a later stage it is easier to reflector the code to use a none static logger as there is only one place to change in the class. It also give a good place to set a breakpoint on when debugging the code, how nice to be able to break into the debugger just after the error has happened, but before the exception is thrown.

Roy,
I don't understand why you are still trying to find difficult ways to break dependancies when there is a FREE tool out that can do the job.
We have over 20 developers using TypeMock.NET (http://www.typemock.com) that does all the dirty work for us.
It save a load of time compared to changing your code trying to make it testable - around 20% compared to the techniques that you discussed.

I agree with Jay that this is not an excuse to write crappy code.
Although it is not an opensource project is still comes with a Free community edition, and no, I am not assosiated with the company.

Eli:
Yes, TypeMock is kinda cool in the easy with which you are able to break things up, but it still can cause trouble. Even with TypeMock.NET - your tests setups might still look horribly unreadable and long if you have many dependencies to break. Sometime just because you have a tool means you have an execuse to write not only slopy code but sloppy tests as well (breaking 10 dependencies before each test is very hard to read and understand rather than seeing two-three lines of code stating that some method is overriden.
Second of all - not all languages have the benefit of using TypeMock.NET - they *have* to resort to more manual means of doing things.

The thing to remember about Mock Objects is that it's an extension of Test-First Programming: it makes most sense when you use it to drive your design. Just adopting Mocks without adjusting your coding style leads to the drawbacks that everyone likes to point out. If you follow the tests, you end up with smaller, focussed objects communicating through interfaces. Done consistently, this leads to a system that's easier to maintain and to reuse.

The best explanation we have at the moment is our OOPLSA paper at: http://www.jmock.org/oopsla2004.pdf

Pingback from  Extract and Conquer! « Relentless Development