Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
NCrunch with Moles
Options
Previous Topic Next Topic
bodie
#1 Posted : Wednesday, October 5, 2011 9:01:29 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 9/13/2011(UTC)
Posts: 7
Location: Kansas

Thanks: 2 times
I realize that there is a hot debate over whether or not to test private methods, but let's just assume, for the moment, that we're going to test them.

I am using Microsoft's PrivateObject class to provide access to the private methods for testing. I am using Moles (from Microsoft Research) to sever the downward dependency when I'm testing the public method that calls the private I already tested. This works well for testing, but NCrunch doesn't seem to know what to do with the test that uses Moles.

Moles is still under Microsoft Research, but is scheduled for a 1.0 product release next month (November 2011). Do you have plans to support the Moles host type attribute in NCrunch?
Back to top
 |  Edit by user
rlarno
#2 Posted : Thursday, October 6, 2011 3:40:09 PM(UTC)
Rank: Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 27
Location: Belgium

Thanks: 6 times
Was thanked: 5 time(s) in 5 post(s)
So why not do the proper thing and make sure you can control your downward dependency, such that you do not need to revert to a solution like Moles?

We had the issue here, we were using Moles for the 'legacy' project and some members of the team suggested to continue using it for the new project. I explained that Moles is great if you can not convince the stakeholders to allow you to make your project more testable (e.g. by using Dependency Inversion). So now we are going TDD (Test Driven Design) and are getting great feedback from NCrunch while writing true unit tests.

Eventually, for NCrunch, it would be great to add Moles support, if at all possible. The way I understand both products instrument/profile the code under test to gain control of what code is being run. I doubt it would be possible to run the MolesHost and still be able to capture the information needed. (Note: I'd love to know more about how these systems work, it is by instrumenting code or is it by using the profiling api, but I don't seem to be able to create the time for such explorations. I'm just really happy there are people building these tools and that they work, though!)
Back to top
bodie
#3 Posted : Thursday, October 6, 2011 3:59:07 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 9/13/2011(UTC)
Posts: 7
Location: Kansas

Thanks: 2 times
How does dependency injection solve the problem? If I have a complex method that contains logic I don't plan to reuse and don't plan to expose, I may extract it into a private method. How do I test that logic without going through the public interface? Then when I want to test the public method, how do I do it without also exercising the code in the private method?

I am admittedly pretty ignorant about IOC and dependency injection, but I'm not seeing the application.
Back to top
Remco
#4 Posted : Thursday, October 6, 2011 7:01:50 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
I think that the general idea behind using DI for a situation like this would be to try to author the tests in a way that would allow you to comfortably test private methods through the public interface. DI proponents would argue that if the private method is complex enough to warrant being isolated for testing, then probably it should be extracted and tested as a separate component/class. I'm personally not big on the idea of testing private methods directly (due to coupling concerns), though naturally I can't hold any bias on this in terms of what NCrunch should or shouldn't allow :)

Anyway, Moles has many other advantages outside of the private/public method testing argument in the fact that it allows you to stub out parts of an application that are not easily abstracted away from a component under test (i.e. HttpContext in ASP.NET).

I haven't yet had time to have a good look at the mechanics of how Moles works. My suspicion is that it would use the profiling API in the same way that TypeMock Isolator does, in which case support for it shouldn't be a big deal (as NCrunch is already integrated with TypeMock Isolator). I'll make a note to have a look at this in a future revision.

Thanks for posting :)
Back to top
2 users thanked Remco for this useful post.
bodie on 10/6/2011(UTC), kipph on 10/27/2011(UTC)
rlarno
#5 Posted : Thursday, October 6, 2011 7:47:46 PM(UTC)
Rank: Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 27
Location: Belgium

Thanks: 6 times
Was thanked: 5 time(s) in 5 post(s)
Hi Body,

Perhaps I was making the wrong assumption about the following:

bodie;473 wrote:
I am using Moles (from Microsoft Research) to sever the downward dependency when I'm testing the public method that calls the private I already tested. This works well for testing, but NCrunch doesn't seem to know what to do with the test that uses Moles.
?


The way I read this is that your code has some external dependency (as on another class). Maybe your intend to say that the public method depends on the private method which you already have tested. And you are using Moles to 'reroute' the call to the private method while testing the public method? In the latter case, DI indeed has no benefit to you.

If however you do have an external dependency, then DI can work wonders for you (and an IoC like Unity, NInject, Munq can help).

Remco, regarding possible support for Moles, as posted we do use it for the legacy version, and would truly appreciate NCrunch support.
Back to top
1 user thanked rlarno for this useful post.
bodie on 10/6/2011(UTC)
bodie
#6 Posted : Thursday, October 6, 2011 8:46:29 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 9/13/2011(UTC)
Posts: 7
Location: Kansas

Thanks: 2 times
rlarno, you nailed it. The dependencies I'm trying to sever are between public methods and the private methods they call. We will probably end up solving the problem in two ways:

1) If the private method is being called by more than one consumer (within the class that contains it), refactor it to a helper class, mark it internal, and test it
2) If the private method is being called by one and only one consumer (again, within the class that contains it), test it directly and mole it when testing the consumer.

It's that second case that makes NCrunch angry.

Thanks for the info, Remco. I'll look forward to seeing that in some future version.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.049 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download