Andrey Shchekin's Blog - Latest Comments in Sins of .NET API Developers

Re: Sins of .NET API Developers

Andrey Shchekin — Sun, 30 Mar 2008 16:30:14 -0000

Jeff, I am sorry for having bashed MbUnit, but for me this post was about common deficiencies, and MbUnit was only an example, since I use it every day.

Andrey, have you tried [assembly: InternalsVisibleTo(RhinoMocks.StrongName)]?

Re: Sins of .NET API Developers

Andrey Titov — Sat, 29 Mar 2008 07:47:30 -0000

I've found another example similar to your #2.
Rhino mock can't create partial mock on non pulic types. So I can't test my BC classes using partial mocking because they are all internal for BL and are accessible outside only with public facade.

Re: Sins of .NET API Developers

Jeff Brown — Fri, 28 Mar 2008 18:35:02 -0000

The best way to ensure that problems are solved is to get involved.

I'm pretty smart and I spend a fair amount of time thinking about these issues upfront so that they are "solved by default." But I will miss stuff or I will postpone it due to conflicting priorities.

So I count on the community of other smart people like yourself to point out deficiencies that affect them so that they can be directly addressed.

Also keep in mind that I only found this post accidentally. So you're lucky I even noticed it at all. The issue tracker and mailing lists are much better ways to ensure that your feedback gets noticed and taken into consideration.

Re: Sins of .NET API Developers

Andrey Shchekin — Wed, 26 Mar 2008 15:38:32 -0000

Thank you, Jeff. I know that I could have asked you directly instead of blogging it, but I wanted to stress the importance of solving these things by default.

As for Gallio, I'll enjoy working with it when it's out, but it is not here yet. So, since I wanted to extend a stable version, I haven't looked deep into Gallio.

Re: Sins of .NET API Developers

Jeff Brown — Wed, 26 Mar 2008 04:42:04 -0000

Gallio and MbUnit v3 have already handily resolved the IFixtureFactory issue you mentioned. The system is much more open to extension now. Components can even be replaced via the IoC if you like.

This is something I have *thought* very carefully about. Trust me. I don't doubt we could do even better. Let me know if you have any ideas. (MbUnit v2 is a different story.)

As for internal test fixtures, this is something we have considered and can very easily change. It's not entirely clear its a good idea. For example, we might encounter problems in partial trust execution environments.

However, you do make a good case regarding the interaction with [InternalsVisibleTo] and the implied constraints on the visibility of any derived types. Previous requests for this feature have largely been from people wanting to mix test fixtures with production code.

In any case I'll go ahead and enable internal fixtures in the next update. Not really worth fussing over.

In the future, if there's anything else you want a tool to do, please just ask for it. It might already be there or it might be something that has just yet to be done pending sufficient demand.

Re: Sins of .NET API Developers

Andrey Shchekin — Tue, 25 Mar 2008 17:07:24 -0000

Thanks, it solves the problem at hand.

Re: Sins of .NET API Developers

Ayende Rahien — Tue, 25 Mar 2008 14:00:31 -0000

Try IKernel.ResolveAll(), it has non generic version