PostSharp

[boo]

So some of the things that drives me absolutely crazy with a lot of testing frameworks and testing methodologies:

- changing the scope of the method so that it can be tested against - public instead of private, protected instead of internal, etc.
- changing inheritance structure so it can be tested against - making method virtual when they have no need to be otherwise, or having to program against a base class whose only derived classes are the 'real' class and the 'test' class
- implementing everything with an interface so it can be tested against.

To me this means you are writing you application for your testing frameworks. Why? The client is not paying you to an application that will work with Test Framework Whatever; they are paying you to write a quality product! How do you do this (besides good requirements and scalable/extensible design?)? Write rock solid code! So as developers we write 1000's of test cases. Some are functional and we use NUnit or MSTest, so are behavioral and we use NMock of RhinoMocks - but each (and other not mentioned) has it's pros and cons; and with any project, at design time, we as developers have to ask ourselves - how are we going to test this? Obviously we need these tests, and these testing tools are really great - but let's not kid ourselves, we really do a lot of coding specifically for our testing framework, and call me old fashioned, but this just doesn't 'smell' right.

So we're left with conundrum of wanting to write maintainable, scalable, well written code, but in order to do that we have to add extra interfaces, make scopes of methods and properties more accessible than they should be, not seal our classes when they should be, etc. In general we're adding extra moving parts which means more lines of codes which is equal to saying 'the application is more complex' which mean more overall cost to the company.

So why couldn't we use AOP to build these test points? It wouldn't seem far fetched that if we used method boundary, we could inject some other code that should be called instead of the 'real' method, this would give us in essence a 'fake/mock' - in fact isn't that already in PostSharp? So then, only in our test project are we injecting code into the assembly, the assembly that gets delivered doesn't have the injection.

So conceptually it seems possible, but obviously there are a lot of implementation details that would need to be addressed and thought out - I can think of dozens already, and at the core is a dynamic weaver instead of a static (how else is an object going to return X in this test and Y in the next test for a fake?); but I haven't seen a dynamic weaver out there that works with the functionality of a static.

Anyway, I wanted to put this out there, to get feedback on whether this is just 'too far out' or maybe if it's not such a bad idea. If it's crap, let me know - you won't hurt my feelings!

Brian

[gfraiteur]

Hi Brian,

I've considered that use case, and I know some people use PostSharp to make testing easier, but finally I decided not to invest in that direction.

I think that purely dynamic solutions are better for this purpose. One can for instance use the Profiling API (as does TypeMock) or the Edit & Continue API.

Another approach would be to compile C# for the DLR, or to transform static MSIL to DLR MSIL, which could be done by PostSharp...

-Gael