Rank 1
The problem we have is that since the .NET CLR can only have one profiler attached at a time, other profilers must go through TypeMock to work. For another profiler to work while TypeMock is running it must be supported by TypeMock. This is a problem when new versions of profilers are released, like the 4.0 version of dotTrace, or when a great profiler isn't supported at all, like Ants from red gate. I'd like to choose which profiler to use based on price, features and how it suits my needs, not based on which one TypeMock likes.
Also, since TypeMock works as profiler and intercepts and alters calls by using the profiling API it can have some pretty odd bugs. Like, for example, it will crash if you try to isolate a call using the Microsoft Entlib Data block in an x64 process.
My three questions about JustMock are:
1. Is it also a "profiler"'?
2. If JustMock is also a profiler, how have you solved the issues with it working together with other profilers?
3. If JustMock is also a profiler, will you strive to make it just as stable in an x64 process as in an x86 process?
1 Answer, 1 is accepted
Thanks a lot for bringing up these questions.
1) I'm pasting one of the comments on the JustMock announcement post which explains how JustMock works:
<quote>
The free mocking frameworks like Rhino Mocks and Moq that you mentioned use the "DynamicProxy approach" and build the mock objects dynamically. I think both these frameworks use an OS project called Castle DynamicProxy. We decided to build our own dynamic proxy library as we wanted something much simpler to meet our mocking needs only.
The advantage of the proxy approach is that these frameworks are quite easy to use as you just need to reference a dll in your unit test project and then just start using the mocking API.
The disadvantage of this approach is that this way you can't mock static methods and classes, sealed classes. non virtual methods and properties and so on.
To mock these things JustMock uses the .NET Profiling API and behaves like a profiler but instead of profiling the code it changes it before the just-in-time compilation and injects code in the original code on-the-fly. You could find more information about this approach here:
http://msdn.microsoft.com/en-gb/magazine/cc188743.aspx
This approach is quite powerful but has its own disadvantages like the hard deployment. You need to have it integrated with your Visual Studio and also with your testing framework and also in some cases its performance is worse compared to how the dynamic proxy approach works.
In JustMock we've tried to take the best of both worlds and that's why we stated that we can bring something new to the table.
</quote>
So in short, JustMock uses the profiler only when necessary - when it mocks static methods and classes, final methods and so on.
2) You should have problems with it only if you're using some profiler to profile tests which use JustMock's profiler (e.g. which mock static stuff, non-virtual members and so on).
We know that this is a limitation which we should try to address soon but we first want to see how many people are profiling such tests so that we give this item the right priority. If it's something that people do often we'll give it a high priority and we'll try to make JustMock play nice with some of the popular profilers.
3) Currently JustMock supports both x86 and x64 processes so you shouldn't have problems with that. Should you have some problems with some specific scenario please contact us and we'll try to assist you.
Hope this information helps.
Kind regards,
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.